lkml.org 
[lkml]   [2014]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC] sched: Add a new lockless wake-from-idle implementation
On Thu, Feb 13, 2014 at 11:58 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra <peterz@infradead.org> 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.
>>
>> ---
>> arch/x86/include/asm/mwait.h | 19 ++++----
>> arch/x86/include/asm/thread_info.h | 4 +-
>> arch/x86/kernel/process.c | 8 ++--
>> include/linux/sched.h | 90 +++-----------------------------------
>> kernel/sched/core.c | 70 ++++++++++++++++++-----------
>> kernel/sched/idle.c | 40 ++++++++---------
>> kernel/sched/sched.h | 3 ++
>> 7 files changed, 88 insertions(+), 146 deletions(-)
>
> This patch changes the default from !polling to polling, right? If
> so, doesn't it break every driver that fails to *clear* the polling
> flag? (My patch is about to have the same problem.)

I'm playing with making polling be the default and I'm seeing all
kinds of erratic behavior. Not sure what's going on. Adding printks
just causes *different* weird behavior. Sigh.

So no updated patch from me today.

--Andy


\
 
 \ /
  Last update: 2014-02-14 03:21    [W:0.065 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site