Re: [PATCH 2 of 4] Introduce i386 fibril scheduling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



let me clarify this: i very much like your AIO patchset in general, in
the sense that it 'completes' the AIO implementation: finally everything
can be done via it, greatly increasing its utility and hopefully its
penetration. This is the most important step, by far.

We violently agree on this :).

what i dont really like /the particular/ concept above - the
introduction of 'fibrils' as a hard distinction of kernel threads. They
are /almost/ kernel threads, but still by being different they create
alot of duplication and miss out on a good deal of features that kernel
threads have naturally.

I might quibble with some of the details, but I understand your fundamental concern. I do. I don't get up each morning *thrilled* by the idea of having to update lockdep, sysrq-t, etc, to understand these fibril things :). The current fibril switch isn't nearly as clever as the lock-free task scheduling switch. It'd be nice if we didn't have to do that work to optimize the hell out of it, sure.

It kind of hurts to say this because i'm usually quite concept-happy -
one can easily get addicted to the introduction of new core kernel
concepts :-)

:)

so my suggestions center around the notion of extending kernel threads
to support the features you find important in fibrils:

would it be hard to redo your AIO patches based on a pool of plain
simple kernel threads?

It'd certainly be doable to throw together a credible attempt to service "asys" system call submission with full-on kernel threads. That seems like reasonable due diligence to me. If full-on threads are almost as cheap, great. If fibrils are so much cheaper that they seem to warrant investing in, great.

I am concerned about the change in behaviour if we fall back to full kernel threads, though. I really, really, want aio syscalls to behave just like sync ones.

Would your strategy be to update the syscall implementations to share data in task_struct so that there isn't as significant a change in behaviour? (sharing current->ioprio, instead if just inheriting it, for example.). We'd be betting that there would be few of these and that they'd be pretty reasonable to share?

- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux