Messages in this thread | | | Subject | Re: [RFC][RT][PATCH 4/4] rtmutex: Ensure only the top waiter or higher priority task can take the lock | From | Steven Rostedt <> | Date | Mon, 03 Jan 2011 23:02:53 -0500 |
| |
On Thu, 2010-12-23 at 17:47 -0500, Steven Rostedt wrote: > plain text document attachment > (0004-rtmutex-Ensure-only-the-top-waiter-or-higher-priorit.patch) > From: Lai Jiangshan <laijs@cn.fujitsu.com> > > In current rtmutex, the pending owner may be boosted by the tasks > in the rtmutex's waitlist when the pending owner is deboosted > or a task in the waitlist is boosted. This boosting is unrelated, > because the pending owner does not really take the rtmutex. > It is not reasonable. >
I'm still hitting some bugs with the port to -rt, but I also noticed something that doesn't look too good.
There's several places in the kernel where a task may release and acquire the same lock multiple times in a row.
The old way of removing the pending owner from the lists and waking it up once, would have the high prio task wake it up once, and then it can grab the locks multiple times without modifying the list, since the pending owner is already awake and not in the pi list anymore.
The new way has the owner remove the woken task from its pi list and wakes it up, but when it steals the lock again, it adds this owner back to its pi list. When it releases the lock, it wakes it up again and removes it from its pi list again. This happens over and over again.
Running dbench, I see this happen (probably on one of the dcache locks) literally a 100 times in a row.
I'm a bit nervous to add this overhead. I'm still working in debug mode so I'm not at a point to do real benchmarks yet.
-- Steve
| |