generic_write_checks() are done in the submission path, not
repeated during
retries, so such types of checks are not intended to run in the aio
thread.
Ah, I see, I was missing the short-cut which avoids re-running parts
of the write path if we're in a retry.
if (!is_sync_kiocb(iocb) && kiocbIsRestarted(iocb)) {
/* nothing to transfer, may just need to sync data */
return ocount;
It's pretty subtle that this has to be placed before the first
significant current reference and that nothing in the path can return
-EIOCBRETRY until after all of the significant current references.
In totally unrelated news, I noticed that current->io_wait is set to
NULL instead of ¤t->__wait after having run the iocb. I wonder
if it shouldn't be saved and restored instead. And maybe update the
comment over is_sync_wait()? Just an observation.
That is great and I look forward to it :) I am, however assuming that
whatever implementation you come up will have a different interface
from current linux aio -- i.e. a next generation aio model, that
will be
easily integratable with kevents etc.
Yeah, that's the hope.
Which takes me back to Ingo's point - lets have the new evolve
parallely
with the old, if we can, and not hold up the patches for POSIX AIO to
start using kernel AIO, or for epoll to integrate with AIO.
Sure, though there are only so many hours in a day :).
OK, I just took a quick look at your blog and I see that you
are basically implementing Linus' microthreads scheduling approach -
one year since we had that discussion.
Yeah. I wanted to see what it would look like.
Glad to see that you found a way to make it workable ...
Wellll, that remains to be seen. If nothing else we'll at least hav
code to point at when discussing it. If we all agree it's not the
right way and dismiss the notion, fine, that's progress :).
(I'm guessing that you are copying over the part
of the stack in use at the time of every switch, is that correct ?
That was my first pass, yeah. It turned the knob a little too far
towards the "invasive but efficient" direction for my taste. I'm now
giving it a try by having full stacks for each blocked op, we'll see
how that goes.
At what
point do you do the allocation of the saved stacks ?
I was allocating at block-time to keep memory consumption down, but I
think my fiddling around with it convinced me that isn't workable.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
