[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0910071237430.3467@gentwo.org>
Date: Wed, 7 Oct 2009 12:42:31 -0400 (EDT)
From: Christoph Lameter <cl@...ux-foundation.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc: Peter Zijlstra <peterz@...radead.org>, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org,
Pekka Enberg <penberg@...helsinki.fi>,
Tejun Heo <tj@...nel.org>, Mel Gorman <mel@....ul.ie>,
mingo@...e.hu
Subject: Re: [this_cpu_xx V5 19/19] SLUB: Experimental new fastpath w/o
interrupt disable
On Wed, 7 Oct 2009, Mathieu Desnoyers wrote:
> preempt_check_resched is basically:
>
> a test TIF_NEED_RESCHED
> if true, call to preempt_schedule
You did not mention the effect of incrementing the preempt counter and
the barrier(). Adds an additional cacheline to a very hot OS path.
Possibly register effects.
> I really don't see what's bothering you here. Testing a thread flag is
> incredibly cheap. That's what is typically added to your fast path.
I am trying to get rid off all unnecessary overhead. These "incredible
cheap" tricks en masse have caused lots of regressions. And the allocator
hotpaths are overloaded with these "incredibly cheap" checks alreayd.
> So, correct behavior would be:
>
> preempt disable()
> fast path attempt
> if (fast path already taken) {
> local_irq_save();
> slow path.
> local_irq_restore();
> }
> preempt_enable()
Ok. If you have to use preempt then you have to suffer I guess..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists