El 17/03/11 16:47, Andrew Morton escribió:
ah, the epic 12309. https://bugzilla.kernel.org/show_bug.cgi?id=12309.
If you're ever wondering how much we suck, go read that one.
I think what we're seeing in 31142 is a large amount of dirty data
buffered against a slow device. Innocent processes enter page reclaim
and end up getting stuck trying to write to that heavily-queued and
slow device.
If so, that's probably what some of the 12309 participants are seeing.
But there are lots of other things in that report too.
Now, the problem you're seeing in 31142 isn't really supposed to
happen. In the direct-reclaim case the code will try to avoid
initiation of blocking I/O against a congested device, via the
bdi_write_congested() test in may_write_to_queue(). Although that code
now looks a bit busted for the order>PAGE_ALLOC_COSTLY_ORDER case,
whodidthat.
However in the case of the new(ish) compaction/migration code I don't
think we're performing that test. migrate_pages()->unmap_and_move()
will get stuck behind that large&slow IO queue if page reclaim decided
to pass it down sync==true, as it apparently has done.
IOW, Mel broke it ;)
I don't quite follow. In my case, the congested device is the USB stick, but the affected processes should be reading/writing on the hard disk. What kind of queue(s) implementation results in pending writes to the USB stick interfering with I/O to the hard
disk? Or am I misunderstanding? I had the (possibly incorrect) impression that each block device had its own I/O queue.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>