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 08/04/11 14:09, Andrea Arcangeli escribio:
> Hi Alex,
>
> On Mon, Apr 04, 2011 at 10:37:44AM -0500, Alex Villaci-s Lasso wrote:
>> Latest update: with 2.6.39-rc1 the stalls only last for a few
>> seconds, but they are still there. So, as I said before, they are
>> reduced but not eliminated.
> Ok from a complete stall for the whole duration of the I/O to a few
> second stall we're clearly going into the right direction.
>
> The few second stalls happen with udf? And vfat doesn't stall?
>
> Minchan rightly pointed out that the (panik) change we made in
> page_alloc.c changes the semantics of the __GFP_NO_KSWAPD bit. I also
> talked with Mel about it. We think it's nicer if we can keep THP
> allocations as close as any other high order allocation as
> possible. There are already plenty of __GFP bits with complex
> semantics. __GFP_NO_KSWAPD is simple and it's nice to stay simple: it
> means the allocation relies on a different kernel daemon for the
> background work (which is khugepaged instead of kswapd in the THP
> case, where khugepaged uses a non intrusive alloc_sleep_millisec
> throttling in case of MM congestion, unlike kswapd would do).
>
> So this is no solution to your problem (if vfat already works I think
> that might be a better solution), but we'd like to know if you get any
> _worse_ stall compared to current 2.6.39-rc, by applying the below
> patch on top of 2.6.39-rc. If this doesn't make any difference, we can
> safely apply it to remove unnecessary complications.
>
> Thanks,
> Andrea
>
> ===
> Subject: compaction: reverse the change that forbid sync migraton with __GFP_NO_KSWAPD
>
> From: Andrea Arcangeli<aarcange@redhat.com>
>
> It's uncertain this has been beneficial, so it's safer to undo it. All other
> compaction users would still go in synchronous mode if a first attempt of async
> compaction failed. Hopefully we don't need to force special behavior for THP
> (which is the only __GFP_NO_KSWAPD user so far and it's the easier to exercise
> and to be noticeable). This also make __GFP_NO_KSWAPD return to its original
> strict semantics specific to bypass kswapd, as THP allocations have khugepaged
> for the async THP allocations/compactions.
>
> Signed-off-by: Andrea Arcangeli<aarcange@redhat.com>
> ---
>   mm/page_alloc.c |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2105,7 +2105,7 @@ rebalance:
>   					sync_migration);
>   	if (page)
>   		goto got_pg;
> -	sync_migration = !(gfp_mask&  __GFP_NO_KSWAPD);
> +	sync_migration = true;
>
>   	/* Try direct reclaim and then allocating */
>   	page = __alloc_pages_direct_reclaim(gfp_mask, order,
>
The stalls occur even with vfat. I am no longer using udf, since (right now) it is not necessary. I will test this patch now.

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