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]