Andrew Morton <[email protected]> wrote:
>
> > If you simply block writes, the system will stall random tasks laundering
> > pages, including those needed to make progress. Even syncing before
> > suspend won't help you, as a running user space may dirty pages.
>
> Well of _course_ that will happen.
Actually, it won't happen. There's already logic in there to help pdflush,
kswapd and memory-allocating tasks avoid blocking on congested queues.
It's trivial to extend that to avoidance of hotunplugged queues.
Things like sync(), fsync(), O_SYNC and reads will necessarily block.
We may or may not decide to block on page-dirtyings. Again, that's trivial
to do in balance_dirty_pages().
Race conditions are pretty much unavoidable - if someone goes and disables
a device when we're partway through and committed to I/O submission then
things will get very sticky. But we can have a pretty successful solution
to all of this without a ton of effort.
But this is all the easy part.
-
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]