From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Mel Gorman <mel@csn.ul.ie>, Jens Axboe <jens.axboe@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Frans Pop <elendil@planet.nl>, Jiri Kosina <jkosina@suse.cz>,
Sven Geggus <lists@fuchsschwanzdomain.de>,
Karol Lewandowski <karol.k.lewandowski@gmail.com>,
Tobias Oetiker <tobi@oetiker.ch>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Rik van Riel <riel@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>,
Stephan von Krawczynski <skraw@ithnet.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH-RFC] cfq: Disable low_latency by default for 2.6.32
Date: Thu, 26 Nov 2009 14:20:57 +0100 [thread overview]
Message-ID: <200911261420.57121.bzolnier@gmail.com> (raw)
In-Reply-To: <1259240937.7371.15.camel@marge.simson.net>
On Thursday 26 November 2009 02:08:57 pm Mike Galbraith wrote:
> On Thu, 2009-11-26 at 12:19 +0000, Mel Gorman wrote:
> > (cc'ing the people from the page allocator failure thread as this might be
> > relevant to some of their problems)
> >
> > I know this is very last minute but I believe we should consider disabling
> > the "low_latency" tunable for block devices by default for 2.6.32. There was
> > evidence that low_latency was a problem last week for page allocation failure
> > reports but the reproduction-case was unusual and involved high-order atomic
> > allocations in low-memory conditions. It took another few days to accurately
> > show the problem for more normal workloads and it's a bit more wide-spread
> > than just allocation failures.
> >
> > Basically, low_latency looks great as long as you have plenty of memory
> > but in low memory situations, it appears to cause problems that manifest
> > as reduced performance, desktop stalls and in some cases, page allocation
> > failures. I think most kernel developers are not seeing the problem as they
> > tend to test on beefier machines and without hitting swap or low-memory
> > situations for the most part. When they are hitting low-memory situations,
> > it tends to be for stress tests where stalls and low performance are expected.
>
> Ouch. It was bad desktop stalls under heavy write that kicked the whole
> thing off.
The problem is that 'desktop' means different things for different people
(for some kernel developers 'desktop' is more like 'a workstation' and for
others it is more like 'an embedded device').
--
Bartlomiej Zolnierkiewicz
--
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:[~2009-11-26 13:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-26 12:19 Mel Gorman
2009-11-26 13:08 ` Mike Galbraith
2009-11-26 13:20 ` Bartlomiej Zolnierkiewicz [this message]
2009-11-26 13:37 ` Mike Galbraith
2009-11-26 13:56 ` Mel Gorman
2009-11-26 13:47 ` Corrado Zoccolo
2009-11-26 14:17 ` Mel Gorman
2009-11-26 15:18 ` Corrado Zoccolo
2009-11-27 11:44 ` Mel Gorman
2009-11-27 12:03 ` Corrado Zoccolo
2009-11-27 15:58 ` Mel Gorman
2009-11-27 18:14 ` Corrado Zoccolo
2009-11-27 18:52 ` Mel Gorman
2009-11-29 15:11 ` Corrado Zoccolo
2009-11-30 12:04 ` Mel Gorman
2009-11-30 12:54 ` Corrado Zoccolo
2009-11-30 15:48 ` Mel Gorman
2009-11-30 17:21 ` Corrado Zoccolo
2009-11-27 5:58 ` KOSAKI Motohiro
2009-11-27 6:29 ` KOSAKI Motohiro
2009-11-27 12:16 ` Mel Gorman
2009-11-30 10:18 ` KOSAKI Motohiro
2009-11-27 4:36 ` KOSAKI Motohiro
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=200911261420.57121.bzolnier@gmail.com \
--to=bzolnier@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=efault@gmx.de \
--cc=elendil@planet.nl \
--cc=jens.axboe@oracle.com \
--cc=jkosina@suse.cz \
--cc=karol.k.lewandowski@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lists@fuchsschwanzdomain.de \
--cc=mel@csn.ul.ie \
--cc=penberg@cs.helsinki.fi \
--cc=riel@redhat.com \
--cc=rjw@sisk.pl \
--cc=skraw@ithnet.com \
--cc=tobi@oetiker.ch \
--cc=torvalds@linux-foundation.org \
/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