LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrea Arcangeli <aarcange@redhat.com>
To: "Jindřich Makovička" <makovick@gmail.com>
Cc: linux-kernel@vger.kernel.org, Mel Gorman <mel@csn.ul.ie>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: khugepaged: gets stuck when writing to USB flash, 2.6.38-rc2
Date: Tue, 1 Feb 2011 16:49:47 +0100	[thread overview]
Message-ID: <20110201154947.GX16981@random.random> (raw)
In-Reply-To: <AANLkTi=uOpN0PwWdGh6iri-vJwuMS+WMPxmaZjv0-TrV@mail.gmail.com>

On Mon, Jan 31, 2011 at 08:28:00PM +0100, Jindřich Makovička wrote:
> Hi,
> 
> I am encountering problems when continuously writing larger amounts of
> data to a USB flash drive. My configuration is
> 
> x86-64 kernel
> USB stick with 10MB/s write, 30MB/s read speed,
> HDD with ~60-80MB/s read/write
> 8 GiB RAM
> 
> When copying 4GB or more in one go from HDD to Flash, during the
> copying, fork() and probably other syscalls involving VM start
> blocking (I first observed the problem in Chrome, which refused to
> display content in new tabs). When one lets the copying finish, the
> system returns to a usable state.
> 
> During the limbo, khugepaged is in D state (uninterruptible sleep).

That means no hugepage could be allocated. Maybe memory compaction is
doing an overwork because all pagecache is dirty and can't be
migrated. This should solve it if it's memory compaction:

echo never >/sys/kernel/mm/transparent_hugepage/defrag

kswapd state would be interesting too. Can you sysrq+t?

Probably we should decrease the aggressiveness of memory compaction in
direct reclaim. I've another report that memory compaction for order <
3 allocations is increasing latency, it's not like your problem but it
may be related. The congestion_wait in compaction.c also makes me
uncomfortable, it should bail out and fail I think. Maybe we should
add a bitflag to differentiate the callers that can gracefully handle
failure (like THP or most skb jumbo frame allocations) and those like
the kernel stack that will return -ENOMEM if allocation fails.

  reply	other threads:[~2011-02-01 15:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-31 19:28 Jindřich Makovička
2011-02-01 15:49 ` Andrea Arcangeli [this message]
2011-02-01 21:24   ` Jindřich Makovička
2011-02-02  0:26     ` Andrea Arcangeli
2011-02-03 13:24   ` Mel Gorman
2011-02-03 19:06     ` Andrea Arcangeli
2011-02-03 21:16       ` Jindřich Makovička
2011-02-04 15:48         ` Andrea Arcangeli
2011-02-13 10:47           ` Jindřich Makovička

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110201154947.GX16981@random.random \
    --to=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=makovick@gmail.com \
    --cc=mel@csn.ul.ie \
    --subject='Re: khugepaged: gets stuck when writing to USB flash, 2.6.38-rc2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).