Messages in this thread | | | Date | Thu, 1 Feb 2007 14:52:15 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 2 of 4] Introduce i386 fibril scheduling |
| |
* Christoph Hellwig <hch@infradead.org> wrote:
> I tend to agree. Note that there is one thing we should be doing one > one day (not only if we want to use it for aio) is to make kernel > threads more lightweight. There a lot of baggae we keep around in > task_struct and co that only makes sense for threads that have a user > space part and aren't or shouldn't be needed for a purely > kernel-resistant thread.
yeah. I'm totally open to such efforts. I'd also be most happy if this was primarily driven via the KAIO effort: i.e. to implement it via kernel threads and then to benchmark the hell out of it. I volunteer to fix whatever fat kernel thread handling has left.
and if people agree with me that 'native' state-machine driven KAIO is where we want to ultimately achieve (it is certainly the best performing implementation) then i dont see the point in fibrils as an interim mechanism anyway. Lets just hide AIO complexities from userspace via kernel threads, and optimize this via two methods: by making kernel threads faster, and by simultaneously and gradually converting as much KAIO code to a native state machine - which would not need any kind of kernel thread help anyway.
(plus as i mentioned previously, co-scheduling kernel threads with related user space threads on the same CPU might be something useful too - not just for KAIO, and we could add that too.)
also, we context-switch kernel threads in 350 nsecs on current hardware and the -rt kernel is certainly happy with that and runs all hardirqs and softirqs in separate kernel thread contexts. There's not /that/ much fat left to cut off - and if there's something more to optimize there then there are a good number of projects interested in that, not just the KAIO effort :)
Ingo - 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/
| |