Re: [Bugme-new] [Bug 31142] New: Large write to USB stick freezes unrelated tasks for a long time

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



El 18/03/11 06:13, Mel Gorman escribió:

\o/ ... no wait, it's the other one - :(

If you look at the stack traces though, all of them had called
do_huge_pmd_anonymous_page() so while it looks similar to 12309, the trigger
is new because it's THP triggering compaction that is causing the stalls
rather than page reclaim doing direct writeback which was the culprit in
the past.

To confirm if this is the case, I'd be very interested in hearing if this
problem persists in the following cases

1. 2.6.38-rc8 with defrag disabled by
    echo never>/sys/kernel/mm/transparent_hugepage/defrag
    (this will stop THP allocations calling into compaction)
2. 2.6.38-rc8 with THP disabled by
    echo never>
/sys/kernel/mm/transparent_hugepage/enabled
    (if the problem still persists, then page reclaim is still a problem
     but we should still stop THP doing sync writes)
3. 2.6.37 vanilla
    (in case this is a new regression introduced since then)

Migration can do sync writes on dirty pages which is why it looks so similar
to page reclaim but this can be controlled by the value of sync_migration
passed into try_to_compact_pages(). If we find that option 1 above makes
the regression go away or at least helps a lot, then a reasonable fix may
be to never set sync_migration if __GFP_NO_KSWAPD which is always set for
THP allocations. I've added Andrea to the cc to see what he thinks.

Thanks for the report.

I have just done tests 1 and 2 on 2.6.38 (final, not -rc8), and I have verified that echoing "never" on either /sys/kernel/mm/transparent_hugepage/defrag or /sys/kernel/mm/transparent_hugepage/enabled does allow the file copy to USB to proceed smoothly (copying 4GB of data). Just to verify, I later wrote "always" to both files, and sure enough, some applications stalled when I repeated the same file copy. So I have at least a workaround for the issue. Given this evidence, will the patch at comment #14 fix the issue for good?

--
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>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]