Re: CONFIG_PREEMPT and server workloads

[Andrea Arcangeli <andrea@suse.de>]

Hi Robert,

On Thu, Mar 18, 2004 at 10:34:22AM -0500, Robert Love wrote:
> I also feel you underestimate the improvements kernel preemption gives. 

Takashi benchmarked the worst case latency in very good detail.  2.6
stock with PREEMPT=y has a worst case latency of 2.4-aa. This is a fact.

With Takashi's lowlatency fixes the latency goes below 2.4-aa, w/ or w/o
PREEMPT.

PREEMPT=y doesn't and cannot improve the worst case latency. This is
true today like it was true 4 years ago.

> Yes, the absolute worst case latency probably remains because it tends
> to occur under lock (although, it is now easier to pinpoint that latency
> and work some magic on the locks).  But the variance of the latency goes
> way down, too.  We smooth out the curve.  And these are differences that
> matter.

I don't think they can matter when the worst case is below 0.2msec.

> And it can be turned off, so if you don't care about that and are not
> debugging atomicity (which preempt is a big help with, right?) then turn
> it off.

I want to implement my aged idea that is to do the opposite of preempt.

I believe that is a much more efficient way to smooth the curve at lower
overhead and no kernel complexity.

Preempt is always enabled as soon as the cpu enters kernel. And it can
be disabled on demand.

I want preempt to be disabled as soon as teh cpu enters kernel, and I
want to enable it on demand _only_ during the copy user, or similar cpu
intensive operations, also guaranteeing that those operations comes to
an end to avoid RCU starvation.

Then I would like to ompare the average latency (the curve) I doubt
they'll be any different, and the overhead will be zero (we've to check
need_resched anyways after a copy-user, so we can as well do
preempt_enable preembt_disable around it).

> Oh, and if the PREEMPT=n overhead is really an issue, then I agree that
> needs to be fixed :)

It's not a big issue of course (very low prio thing ;).