linux-kernel - Re: [ANNOUNCE] 3.2.9-rt17

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1331242574.25686.505.camel@gandalf.stny.rr.com>
Date:	Thu, 08 Mar 2012 16:36:14 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>
Subject: Re: [ANNOUNCE] 3.2.9-rt17

On Thu, 2012-03-08 at 22:28 +0100, Peter Zijlstra wrote:
> On Thu, 2012-03-08 at 16:25 -0500, Steven Rostedt wrote:
> > 
> > How would this be different than what mainline does? When the lock is
> > released, it will wake up the other task. 
> 
> mainline has ticket locks, the rt-mutex stuff has equal priority lock
> stealing, waking up the blocked task will take so long our running loop
> will have re-acquired ->d_lock again before it even gets to trying.

And we have adaptive mutexes.

So we wake up the task (now with the higher priority), by the time it
wakes up, the original task retook the lock. But because of adaptive
mutexes, as this task takes the lock it notices that the owner is still
running, and it will spin and not sleep.

Now when the original task releases the lock again, the other task can
take it just like it does on mainline.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/