Messages in this thread | | | Date | Wed, 15 Sep 2004 08:19:22 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] sched: fix scheduling latencies for !PREEMPT kernels |
| |
* 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |