From: Mel Gorman <mgorman@suse.de>
To: Jim Schutt <jaschut@sandia.gov>
Cc: Rik van Riel <riel@redhat.com>, Linux-MM <linux-mm@kvack.org>,
Minchan Kim <minchan@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] mm: have order > 0 compaction start near a pageblock with free pages
Date: Tue, 7 Aug 2012 16:45:26 +0100 [thread overview]
Message-ID: <20120807154526.GH29814@suse.de> (raw)
In-Reply-To: <50213228.1030107@sandia.gov>
On Tue, Aug 07, 2012 at 09:20:08AM -0600, Jim Schutt wrote:
> On 08/07/2012 08:52 AM, Mel Gorman wrote:
> >On Tue, Aug 07, 2012 at 10:45:25AM -0400, Rik van Riel wrote:
> >>On 08/07/2012 08:31 AM, Mel Gorman wrote:
> >>>commit [7db8889a: mm: have order> 0 compaction start off where it left]
> >>>introduced a caching mechanism to reduce the amount work the free page
> >>>scanner does in compaction. However, it has a problem. Consider two process
> >>>simultaneously scanning free pages
> >>>
> >>> C
> >>>Process A M S F
> >>> |---------------------------------------|
> >>>Process B M FS
> >>
> >>Argh. Good spotting.
> >>
> >>>This is not optimal and it can still race but the compact_cached_free_pfn
> >>>will be pointing to or very near a pageblock with free pages.
> >>
> >>Agreed on the "not optimal", but I also cannot think of a better
> >>idea right now. Getting this fixed for 3.6 is important, we can
> >>think of future optimizations in San Diego.
> >>
> >
> >Sounds like a plan.
> >
> >>>Signed-off-by: Mel Gorman<mgorman@suse.de>
> >>
> >>Reviewed-by: Rik van Riel<riel@redhat.com>
> >>
> >
> >Thanks very much.
> >
> >Jim, what are the chances of getting this series tested with your large
> >data workload? As it's on top of 3.5, it should be less scary than
> >testing 3.6-rc1 but if you are comfortable testing 3.6-rc1 then please
> >test with just this patch on top.
> >
>
> As it turns out I'm already testing 3.6-rc1, as I'm on
> the trail of a Ceph client messaging bug. I think I've
> about got that figured out, and am working on a patch, but
> I need it fixed in order to generate enough load to trigger
> the problem that your patch addresses.
>
Grand, good luck with the Ceph bug.
> Which is a long-winded way of saying: no problem, I'll
> roll this into my current testing, but I'll need another
> day or two before I'm likely to be able to generate a
> high enough load to test effectively. OK?
>
That is perfectly reasonable, thanks.
> Also FWIW, it occurs to me that you might be interested
> to know that my load also involves lots of network load
> where I'm using jumbo frames. I suspect that puts even
> more stress on higher page order allocations, right?
>
It might. It depends on whether the underlying driver needs contiguous
pages to handle jumbo frame, if it can do scatter/gather IO or some
combination like trying for a contiguous page but using scatter/gather as
a fallback. Certainly it is interesting and I will keep it in mind.
--
Mel Gorman
SUSE Labs
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-08-07 15:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 12:31 [RFC PATCH 0/6] Improve hugepage allocation success rates under load Mel Gorman
2012-08-07 12:31 ` [PATCH 1/6] mm: compaction: Update comment in try_to_compact_pages Mel Gorman
2012-08-07 13:19 ` Rik van Riel
2012-08-07 23:25 ` Minchan Kim
2012-08-07 12:31 ` [PATCH 2/6] mm: vmscan: Scale number of pages reclaimed by reclaim/compaction based on failures Mel Gorman
2012-08-07 13:23 ` Rik van Riel
2012-08-08 1:48 ` Minchan Kim
2012-08-08 7:55 ` Mel Gorman
2012-08-08 8:27 ` Minchan Kim
2012-08-08 8:51 ` Mel Gorman
2012-08-08 23:51 ` Minchan Kim
2012-08-09 7:49 ` Mel Gorman
2012-08-09 8:27 ` Minchan Kim
2012-08-09 9:20 ` Mel Gorman
2012-08-09 20:29 ` Rik van Riel
2012-08-10 8:14 ` Mel Gorman
2012-08-09 23:27 ` Minchan Kim
2012-08-10 8:34 ` Mel Gorman
2012-08-10 8:48 ` Minchan Kim
2012-08-07 12:31 ` [PATCH 3/6] mm: kswapd: Continue reclaiming for reclaim/compaction if the minimum number of pages have not been reclaimed Mel Gorman
2012-08-07 13:26 ` Rik van Riel
2012-08-08 2:07 ` Minchan Kim
2012-08-08 9:07 ` Mel Gorman
2012-08-08 9:58 ` Mel Gorman
2012-08-07 12:31 ` [PATCH 4/6] mm: compaction: Capture a suitable high-order page immediately when it is made available Mel Gorman
2012-08-07 13:30 ` Rik van Riel
2012-08-07 12:31 ` [PATCH 5/6] mm: have order > 0 compaction start off where it left Mel Gorman
2012-08-07 12:31 ` [PATCH 6/6] mm: have order > 0 compaction start near a pageblock with free pages Mel Gorman
2012-08-07 14:45 ` Rik van Riel
2012-08-07 14:52 ` Mel Gorman
2012-08-07 15:20 ` Jim Schutt
2012-08-07 15:45 ` Mel Gorman [this message]
2012-08-08 4:36 ` Minchan Kim
2012-08-08 10:18 ` Mel Gorman
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=20120807154526.GH29814@suse.de \
--to=mgorman@suse.de \
--cc=jaschut@sandia.gov \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).