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  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]
Date:	Fri, 14 Feb 2014 12:17:27 -0800
From:	Andy Lutomirski <>
To:	Peter Zijlstra <>
Cc:	Thomas Gleixner <>,
	Mike Galbraith <>, X86 ML <>,
	"" <>
Subject: Re: [RFC] sched: Add a new lockless wake-from-idle implementation

On Fri, Feb 14, 2014 at 12:01 PM, Andy Lutomirski <> wrote:
> On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra <> wrote:
>> On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
>>> This is a strawman proposal to simplify the idle implementation, eliminate
>>> a race
>>> Benefits over current code:
>>>  - ttwu_queue_remote doesn't use an IPI unless needed
>>>  - The diffstat should speak for itself :)
>>>  - Less racy.  Spurious IPIs are possible, but only in narrow windows or
>>>    when two wakeups occur in rapid succession.
>>>  - Seems to work (?)
>>> Issues:
>>>  - Am I doing the percpu stuff right?
>>>  - Needs work on non-x86 architectures
>>>  - The !CONFIG_SMP case needs to be checked
>>>  - Is "idlepoll" a good name for the new code?  It doesn't have *that*
>>>    much to do with the idle state.  Maybe cpukick?
>>> If this turns out okay, TIF_NEED_RESCHED could possibly be deleted as well.
>> No, we can't do away with that; its used in some fairly critical paths
>> (return to userspace) and adding a second cacheline load there would be
>> unfortunate.
>> I also don't really like how the polling state is an atomic; its a cpu
>> local property.
>> Now given we can't get rid of TIF_NEED_RESCHED, and we need an atomic op
>> on a remote cacheline anyhow; the simplest solution would be to convert
>> all TS_POLLING users to TIF_POLLING_NRFLAG and use an atomic_or_return()
>> like construct to do:
>>   atomic_or_return(&ti->flags, _TIF_NEED_RESCHED) & _TIF_POLLING_NRFLAG
>> and avoid the IPI if that is false.
>> Something a little like this; it does require a lot of auditing; but it
>> boots on my x86_64.
> On further consideration, I think I like this approach.  It's a
> simpler change than mine and it appears to work (unlike mine, and I
> still haven't figured out what I'm doing wrong).  If anyone wants to
> get rid of the cmpxchg loop, a trick like would likely work well built
> on top of this.
> That being said, I can't really test this, because I can't seem to
> boot any recent 3.14-based kernel on real hardware, and they die
> before they produce any output.  They work fine in QEMU.

Either you have a bug or I rebased it wrong.  With the attached
rebased version, I hit WARN_ON_ONCE(irqs_disabled()) in
cpu_idle_loop() on a semi-regular basis when I boot with:

virtme-runkernel arch/x86/boot/bzImage -smp 2 -cpu host

It also sometimes hangs after starting a shell.

(shameless plug: this is virtme from  )


View attachment "peterz2.patch" of type "text/x-diff" (11512 bytes)

Powered by blists - more mailing lists