On Thu, Aug 25 2005, Ingo Molnar wrote:
>
> * Jens Axboe <[email protected]> wrote:
>
> > There can quite easily be lots of pending IO for the io_context (and,
> > in CFQ's case, below cfq_io_contexts), task exiting is completely
> > decoupled from any pending io.
>
> yes, but that only affects the io_context reference count. Actual new
> use of tsk->io_context should only be possible on the IO-submission
> side, which should all have stopped by the time we execute do_exit().
> (and it's synchronous anyway, so the fact that we are executing in the
> kernel prevents the same thread from submitting new IO, in this case.)
>
> i.e. the removal of tsk->io_context can be done without locking out
> interrupts. No interrupt or io_context is supposed to access
> current->io_context at that point.
Well that's not quite correct, changes were made that allow lookup of
the cic from another task. What happens is that process A will be
dirtying lots of data and process B will be quitely reading other data.
Process B can then get unlucky and have to do page reclaim on behalf of
process A, simply because it tries to allocate a page under memory
pressure.
This is probably fairly rare, because async writeout goes to a dedicated
queue typically bound to one (or more) of the pdflush threads which
never exit. None the less, it needs fixing.
This used to be safe (it used rcu and the cfq_cic_lock to protect read
and write side respectively), I _think_ this was dropped at some point
because I dropped the cross-lookup. I have to ponder how best to fix
this...
--
Jens Axboe
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |