From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>, Greg Kroah-Hartman <gregkh@suse.de>,
Kyle McMartin <kyle@mcmartin.ca>,
Shaohua Li <shaohua.li@intel.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Christoph Lameter <cl@linux.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 1/2] mm: page allocator: Adjust the per-cpu counter threshold when memory is low
Date: Thu, 23 Dec 2010 15:07:02 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.1012231456520.2116@chino.kir.corp.google.com> (raw)
In-Reply-To: <20101223143521.f94a5106.akpm@linux-foundation.org>
On Thu, 23 Dec 2010, Andrew Morton wrote:
> > We had to pull aa454840 "mm: page allocator: calculate a better estimate
> > of NR_FREE_PAGES when memory is low and kswapd is awake" from 2.6.36
> > internally because tests showed that it would cause the machine to stall
> > as the result of heavy kswapd activity. I merged it back with this fix as
> > it is pending in the -mm tree and it solves the issue we were seeing, so I
> > definitely think this should be pushed to -stable (and I would seriously
> > consider it for 2.6.37 inclusion even at this late date).
>
> How's about I send
> mm-page-allocator-adjust-the-per-cpu-counter-threshold-when-memory-is-low.patch
> in for 2.6.38 and tag it for backporting into 2.6.37.1 and 2.6.36.x?
> That way it'll get a bit of 2.6.38-rc testing before being merged into
> 2.6.37.x.
>
I don't think anyone would be able to answer that judgment call other than
you or Linus, it's a trade-off on whether 2.6.37 should be released with
the knowledge that it regresses just like 2.6.36 does (rendering both
unusable on some of our machines out of the box) because we're late in the
cycle.
I personally think the testing is already sufficient since it's been
sitting in -mm for two months, it's been suggested as stable material by a
couple different parties, it was a prerequisite for the transparent
hugepage series, and we've tested and merged it as fixing the regression
in 2.6.36 (as Fedora has, as far as I know). We've already merged the fix
internally, though, so it's not for selfish reasons :)
--
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 policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-12-24 0:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 8:47 [PATCH 0/2] Reduce the amount of time spent in watermark-related functions Mel Gorman
2010-10-27 8:47 ` [PATCH 1/2] mm: page allocator: Adjust the per-cpu counter threshold when memory is low Mel Gorman
2010-10-27 20:16 ` Christoph Lameter
2010-10-28 1:09 ` KAMEZAWA Hiroyuki
2010-10-28 9:49 ` Mel Gorman
2010-10-28 9:58 ` KAMEZAWA Hiroyuki
2010-11-14 8:53 ` [PATCH] set_pgdat_percpu_threshold() don't use for_each_online_cpu KOSAKI Motohiro
2010-11-15 10:26 ` Mel Gorman
2010-11-15 14:04 ` Christoph Lameter
2010-11-16 9:58 ` Mel Gorman
2010-11-17 0:07 ` Andrew Morton
2010-11-19 15:29 ` Christoph Lameter
2010-11-23 8:32 ` KOSAKI Motohiro
2010-11-01 7:06 ` [PATCH 1/2] mm: page allocator: Adjust the per-cpu counter threshold when memory is low KOSAKI Motohiro
2010-11-26 16:06 ` Kyle McMartin
2010-11-29 9:56 ` Mel Gorman
2010-11-29 13:16 ` Kyle McMartin
2010-11-29 15:08 ` Mel Gorman
2010-11-29 15:22 ` Kyle McMartin
2010-11-29 15:26 ` Kyle McMartin
2010-11-29 15:58 ` Mel Gorman
2010-12-23 22:18 ` David Rientjes
2010-12-23 22:35 ` Andrew Morton
2010-12-23 23:00 ` Kyle McMartin
2010-12-23 23:07 ` David Rientjes [this message]
2010-12-23 23:17 ` Andrew Morton
2010-10-27 8:47 ` [PATCH 2/2] mm: vmstat: Use a single setter function and callback for adjusting percpu thresholds Mel Gorman
2010-10-27 20:13 ` Christoph Lameter
2010-10-28 1:10 ` KAMEZAWA Hiroyuki
2010-11-01 7:06 ` KOSAKI Motohiro
2010-10-28 15:13 [PATCH 0/2] Reduce the amount of time spent in watermark-related functions V4 Mel Gorman
2010-10-28 15:13 ` [PATCH 1/2] mm: page allocator: Adjust the per-cpu counter threshold when memory is low Mel Gorman
2010-10-28 22:04 ` Andrew Morton
2010-10-29 10:12 ` Mel Gorman
2010-10-29 19:40 ` Andrew Morton
2010-11-02 0:53 ` Shaohua Li
2010-11-09 11:33 ` Mel Gorman
2010-11-09 16:48 ` Christoph Lameter
2010-10-29 14:58 ` Christoph Lameter
2010-10-29 18:25 ` Andrew Morton
2010-10-29 19:33 ` Christoph Lameter
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=alpine.DEB.2.00.1012231456520.2116@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=gregkh@suse.de \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=kyle@mcmartin.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=shaohua.li@intel.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