Messages in this thread | | | Date | Wed, 15 Sep 2004 18:23:48 +1000 | From | Nick Piggin <> | Subject | Re: [patch] sched: fix scheduling latencies for !PREEMPT kernels |
| |
Ingo Molnar wrote: > * 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. >
OK, this one thing isn't going to be noticable. But why you really must have the check for every page, and not in the logical place where we batch them up? You're obviously aiming for the lowest latencies possible *without* CONFIG_PREEMPT.
But I'm thinking, why add overhead for people who don't care about sub-ms latency (ie. most of us)? And at the same time, why would anyone in a latency critical environment not enable preempt?
> The function (cond_resched()) triggers scheduling only very rarely, you > should not be worried about that aspect either. >
No, I'm not worried about that.
> >>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. >
OK.
Alternatively, I'd say tell everyone who wants really low latency to enable CONFIG_PREEMPT, which automatically gives the minimum possible preempt latency, delimited (and defined) by critical sections, instead of the more ad-hoc "sprinkling" ;) - 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/
| |