linux-kernel - Re: [PATCH] mm: Do not stall in synchronous compaction for THP allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 10 Nov 2011 13:06:49 +0100
From:	Johannes Weiner <jweiner@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Mel Gorman <mgorman@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jan Kara <jack@...e.cz>, Andy Isaacson <adi@...apodia.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: Do not stall in synchronous compaction for THP
 allocations

On Thu, Nov 10, 2011 at 10:51:00AM +0000, Alan Cox wrote:
> On Thu, 10 Nov 2011 10:06:16 +0000
> Mel Gorman <mgorman@...e.de> wrote:
> 
> > Occasionally during large file copies to slow storage, there are still
> > reports of user-visible stalls when THP is enabled. Reports on this
> > have been intermittent and not reliable to reproduce locally but;
> 
> If you want to cause a massive stall take a cheap 32GB USB flash drive
> plug it into an 8GB box and rsync a lot of small files to it. 400,000
> emails in maildir format does the trick and can easily be simulated. The
> drive drops to about 1-2 IOPS with all the small mucking around and the
> backlog becomes massive.
> 
> > Internally in SUSE, I received a bug report related to stalls in firefox
> > 	when using Java and Flash heavily while copying from NFS
> > 	to VFAT on USB. It has not been confirmed to be the same problem
> > 	but if it looks like a duck and quacks like a duck.....
> 
> With the 32GB USB flash rsync I see firefox block for up to 45 minutes
> although operating entirely on an unrelated filesystem. I suspect it may
> be a problem that is visible because an fsync is getting jammed up in
> the mess.

Compaction walks PFN ranges, oblivious to inode dirtying order, and so
transparent huge page allocations can get stuck repeatedly on pages
under writeback that are behind whatever the bdi's queue allows to be
inflight.

On all hangs I observed while writing to my 16GB USB thumb drive, it
was tasks getting stuck in migration when allocating a THP.

Can you capture /proc/`pidof firefox`/stack while it hangs to see if
what you see is, in fact, the same problem?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/