On Mon, Oct 08, 2001 at 09:11:57AM -0600, Eric W. Biederman wrote:
> > IF the kernel becomes preemptible it will be so slow, so buggy, and so painful
> > to maintain, that those issues won't matter.
>
> The preemptible kernel work just takes the current SMP code, and
> allows it to work on a single processor. You are not interruptted if
> you have a lock held. This makes the number of cases in the kernel
> simpler, and should improve maintenance as more people will be
> affected by the SMP issues.
i.e. "since we are already committed to making the kernel more complex, slower, and
harder to maintain, there is no problem ... "
>
> Right now there is a preemptible kernel patch being maintained
> somewhere. I haven't had a chance to look recently. But the recent
> threads on low latency mentioned it.
Try it out. Try running a kernel compile while a POSIX SCHED_FIFO process
is running.
> As for rules. They are the usual SMP rules. In earlier version there
> was a requirement or that you used balanced constructs.
I'm sorry, but this is not correct. SMP is different from low-latency and
has different goals. You certainly can piggyback low-latency of a sort on
on the finer-grained locking you get from SMP support, but if you optimize
a kernel for SMP support you don't necessarily look at the same lock issues
as you would if your goal was to reduce latency. E.g. for SMP a design like
each processor maintains a local cache of resource X. Getting X from
the local cache takes 100ns and only local locking.
there is a slow and expensive spin locked central resource for X
used to replenish local caches. Getting X from the central resource
takes 1 second.
Cache success rate is over 99.99%.
With 10000 accesses to X, total time is 1.01 seconds for an average of 100 microseconds and this
is overstating the case, for most processes never see the 1second delay and average
100ns per access.
But worst case is 1 second!
If you were to design for low latency, you'd prefer the design
an elaborate resource control mechanism allows all processors to
share X and get X resources within 1 millisecond.
1000 times better latency, 10000 times worse average case.
You cannot escape a tradeoff by pretending it's not there.
Look we handle this all the time in RTLinux: we have to throw away heartbreakingly
beautiful solutions because worst case numbers are bad.
-
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/
This archive was generated by hypermail 2b29 : Mon Oct 15 2001 - 21:00:18 EST