Messages in this thread | | | Date | Wed, 21 Jul 2004 15:31:44 -0700 | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch | From | Bill Huey (hui) <> |
| |
On Wed, Jul 21, 2004 at 03:14:23PM -0700, Bill Huey wrote: > On Wed, Jul 21, 2004 at 11:18:26PM +0200, Ingo Molnar wrote: > > trying to make softirqs preemptible surely wont fly for 2.6 and it will > > also overly complicate the softirq model. What's so terminally wrong > > about adding preemption checks to the softirq paths? It should solve the > > preemption problem for good. The unbound softirq paths are well-known > > (mostly in the networking code) and already have preemption-alike > > checks. > > These folks are tring to make the entire kernel fully preemptable, > possibly, to handle arbitrary preemption at any point during the > execution. It's a noble task to make the kernel preemptable in that > way, but what I've seen is that the use of non-preemptive critical > sections commits all locks below it in the call/lock graph to also > be non-preemptive critical sections and therefore forcing the use > of traditional lock-break and other techniques to lower latency.
One thing that would preserve the correctness of this system might be to use a per-CPU blocking lock to directly back the uses of local_bh_* functions explicitly. This altered system would be functionally isomorphic, but would permit preemption in bhs.
This is something I've been thinking about for a while so it could be off track or wrong and I'm open (pleading) for correction.
It's a radical departure from the current "deferred-everthing" model that Linux and many other general purpose OSes are currently using. The overall performance penalty is unknown, but the possiblity of lowering latency could still be very significant.
bill
- 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/
| |