Messages in this thread | | | Subject | Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools | From | Benjamin Herrenschmidt <> | Date | Thu, 03 Jul 2008 20:31:26 +1000 |
| |
On Thu, 2008-07-03 at 03:12 -0700, Eric W. Biederman wrote: > Benjamin Herrenschmidt <benh@kernel.crashing.org> writes: > > > The question is: is that significantly less overhead than just spawning > > a new full blown kernel thread ? enough to justify the complexity ? at > > the end of the day, it means allocating a stack (which on ppc64 is still > > 16K, I know it sucks)... > > I looked at this a while ago. And right now kernel_thread is fairly light. > kthread_create has latency issues because we need to queue up a task on > our kernel thread spawning daemon, and let it fork the child. Needing > to go via the kthread spawning daemon didn't look fundamental, just something > that was a challenge to sort out.
Yes. I was thinking that if it becomes an issue, we could special case something in the scheduler to pop them.
Ben.
| |