linux-kernel - Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning

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: <g7pqnsfk8rndpulc64UYAxe124vaj_firegpg@mail.gmail.com>
Date:	Tue, 6 Apr 2010 23:08:56 -0700 (PST)
From:	drepper@...il.com
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Darren Hart <dvhltc@...ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Avi Kivity <avi@...hat.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"Peter W. Morreale" <pmorreale@...ell.com>,
	Rik van Riel <riel@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Sven-Thorsten Dietrich <sdietrich@...ell.com>,
	Chris Mason <chris.mason@...cle.com>,
	John Cooper <john.cooper@...rd-harmonic.com>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: [PATCH V2 0/6][RFC] futex: FUTEX_LOCK with optional adaptive spinning

On Tue, Apr 6, 2010 at 16:16, Thomas Gleixner <tglx@...utronix.de> wrote:
> I know that you can do any weird stuff with the futex value, but I
> don't see the "dramatic" limitation. Care to elaborate ?

If we have to fill in the PID we can represent only three states in a futex: 0, PID, -PID.  Today we can represent 2^32 states.  Quite a difference.

> The per thread pinned page would be unconditional, right ?

Only if the process would be using these adaptive mutexes.  It could be conditional.

> I agree that benchmarking would be interesting, but OTOH I fear that
> we open up a huge can of worms with exposing scheduler details and the
> related necessary syscalls like sys_yield_to: User space thread
> management/scheduling comes to my mind and I hope we agree that we do
> not want to revisit that.

I'm not sure.  We never got to the bottom of this.  Why are these details which should not be disclosed?  It's clear that there is descheduling and the sys_yield_to syscall would require nothing to happen but indicate to the kernel execution dependencies the kernel cannot necessarily discover on its own, at least not efficiently.

> Useful for what ?

We already have places where we could spin a bit using sys_yield_to because be know what we are waiting on.

> What are the exact semantics of such a syscall ?

It gives the kernel the hint that the current thread is willing to hand over the remaining time on the timeslice to the target thread.  This target thread, if sleeping, can immediately make progress.  Yes, this might mean moving the target thread to the core executing yielding thread.  Perhaps this doesn't make sense in some situations.  In this case the syscall could be a no-op, perhaps indicating this in the return value.

> How does that fit into the various scheduling constraints ?

I don't know enough about all the constraints.  As I said, it could be a hint.  If the constraints forbid the timeslice transfer it need not happen.
Download attachment "signature.asc" of type "application/pgp-signature" (273 bytes)