Messages in this thread | | | From | (Eric W. Biederman) | Date | Thu, 03 Jul 2008 03:12:51 -0700 | Subject | Re: [Ksummit-2008-discuss] Delayed interrupt work, thread pools |
| |
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.
Eric
| |