Re: [patch] sched: fix scheduling latencies for !PREEMPT kernels

Ingo Molnar
2004-09-15T06:18:01Z

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> No, but I mean putting them right down into fastpaths like the vmscan
> one, for example.

it is a very simple no-parameters call to a function that reads a
likely-cached word and returns. The cost is in the 2-3 cycles range - a
_single_ cachemiss can be 10-100 times more expensive, and cachemisses
happen very frequently in every iteration of the VM _scanning_ path
since it (naturally and inevitably) deals with lots of sparsely
scattered data structures that havent been referenced for quite some
time.

The function (cond_resched()) triggers scheduling only very rarely, you
should not be worried about that aspect either.

> And if I remember correctly, you resorted to putting them into
> might_sleep as well (but I haven't read the code for a while, maybe
> you're now getting decent results without doing that).

i'm not arguing that now at all, that preemption model clearly has to be
an optional thing - at least initially.

Ingo