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

["Alex Villací­s Lasso" <avillaci@fiec.espol.edu.ec>]

El 19/03/11 08:46, Mel Gorman escribio:
> On Fri, Mar 18, 2011 at 01:05:15PM -0500, Alex Villac??s Lasso wrote:
>> El 18/03/11 06:13, Mel Gorman escribio:
>>> \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?
>>
> Thanks for testing and reporting, it's very helpful. Based on that that
> report the patch should help. Can you test it to be absolutly sure please?
>
>
The patch did not help. I have attached a sysrq-w trace with the patch applied in the bug report.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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@kvack.org"> email@kvack.org </a>