Messages in this thread | | | Date | Mon, 12 Aug 2013 19:58:30 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC] per-cpu preempt_count |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Aug 12, 2013 at 4:51 AM, Peter Zijlstra <peterz@infradead.org> wrote: > > > > The below boots to wanting to mount a root filesystem with > > CONFIG_PREEMPT=y using kvm -smp 4. > > But doesn't work in general? Or you just never tested?
(I think Peter never tested it on real hw - this is an RFC patch to show the concept .)
> > Adding TIF_NEED_RESCHED into the preempt count would allow a single > > test in preempt_check_resched() instead of still needing the TI. > > Removing PREEMPT_ACTIVE from preempt count should allow us to get rid > > of ti::preempt_count altogether. > > > > The only problem with TIF_NEED_RESCHED is that its cross-cpu which > > would make the entire thing atomic which would suck donkey balls so > > maybe we need two separate per-cpu variables? > > Agreed. Making it atomic would suck, and cancel all advantages of the > better code generation to access it. Good point.
We could still have the advantages of NEED_RESCHED in preempt_count() by realizing that we only rarely actually set/clear need_resched and mostly read it from the highest freq user, the preempt_enable() check.
So we could have it atomic, but do atomic_read() in the preempt_enable() hotpath which wouldn't suck donkey balls, right?
That would allow a really sweet preempt_enable() fastpath, on x86 at least.
Thanks,
Ingo
| |