> On Tue, 2002-01-08 at 15:59, Daniel Phillips wrote:
>
> > And while I'm enumerating differences, the preemptable kernel (in this
> > incarnation) has a slight per-spinlock cost, while the non-preemptable kernel
> > has the fixed cost of checking for rescheduling, at intervals throughout all
> > 'interesting' kernel code, essentially all long-running loops. But by clever
> > coding it's possible to finesse away almost all the overhead of those loop
> > checks, so in the end, the non-preemptible low-latency patch has a slight
> > efficiency advantage here, with emphasis on 'slight'.
>
> True (re spinlock weight in preemptible kernel) but how is that not
> comparable to explicit scheduling points? Worse, the preempt-kernel
> typically does its preemption on a branch on return to interrupt
> (similar to user space's preemption). What better time to check and
> reschedule if needed?
I'm not sure that preempt and low latency really are attacking the same
problem. What I am finding is the LL improves overall performance when a
process does something which is physically slow, like a find in a
directory with 20k files. On the other hand PK makes the response of the
system better to changes. In particular I see the DNS servers which have
other work running, even backups or reports, are more responsive with PK,
as are usenet news servers. I find it hard to measure "feels faster" with
either approach, although like the supreme court "I know it when I see
it."
I'd like to hope that some of each will get in the main kernel, PK has
been stable for me for a while, LL has never been unstable but I've run it
less.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.- 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/