lkml.org 
[lkml]   [2013]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] per-cpu preempt_count
From
On Tue, Aug 13, 2013 at 9:29 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
> The inverted need_resched that gives decl+jnz idea from Ingo should do
> it though.

I agree that that is a good approach.

> Not entirely sure I understand your MSB + jns suggestion:
>
> 0x80000002 - 1 = 0x80000001
>
> Both are very much signed and neither wants to cause a reschedule.

The thing is, we don't check the preempt count even currently, so the
above isn't fatal. The "need preemption" bit being set (or reset with
the reverse bit meaning) should be the unusual case with preemption
(you have to hit the race), *and* it should be unusual to have deeply
nested preemption anyway, so it's fine to test that in the slow path
(and we do: preempt_schedule() checks the preempt count being zero and
irqs being disabled, *exactly* because the preemption enable check
isn't precise).

But avoiding a few sloppy cases is certainly good, even if they are
unusual, so I do like the reversed bit approach. It also allows us to
pick any arbitrary bit, although I'm not sure that matters much.

Linus


\
 
 \ /
  Last update: 2013-08-14 07:01    [W:0.044 / U:1.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site