linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: kosaki.motohiro@jp.fujitsu.com,
	Corrado Zoccolo <czoccolo@gmail.com>,
	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>,
	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: Mon, 30 Nov 2009 19:18:18 +0900 (JST)	[thread overview]
Message-ID: <20091130190711.5BFF.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <20091127121627.GL13095@csn.ul.ie>

> On Fri, Nov 27, 2009 at 02:58:26PM +0900, KOSAKI Motohiro wrote:
> > > > <SNIP>
> > > > low_latency was tested on other scenarios:
> > > > http://lkml.indiana.edu/hypermail/linux/kernel/0910.0/01410.html
> > > > http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-11/msg04855.html
> > > > where it improved actual and perceived performance, so disabling it
> > > > completely may not be good.
> > > > 
> > > 
> > > It may not indeed.
> > > 
> > > In case you mean a partial disabling of cfq_latency, I'm try the
> > > following patch. The intention is to disable the low_latency logic if
> > > kswapd is at work and presumably needs clean pages. Alternative
> > > suggestions welcome.
> > 
> > I like treat vmscan writeout as special. because
> >   - vmscan use various process context. but it doesn't write own process's page.
> >     IOW, it doesn't so match cfq's io fairness logic.
> >   - plus, the above mean vmscan writeout doesn't need good i/o latency.
> 
> While it might not need good latency as such, it does need pages to be
> clean because direct reclaim has trouble cleaning pages in its own
> behalf.

Well.
if direct reclaim need lumpy reclaim, you are right.

In no lupy case, vmscan start pageout and move the page list tail typically.
cleaned page will be used by another task.

---------------------------------------------------------------------------------------
static unsigned long shrink_page_list(struct list_head *page_list,
                                      struct list_head *freed_pages_list,
                                        struct scan_control *sc,
                                        enum pageout_io sync_writeback)
{
(snip)
                        switch (pageout(page, mapping, sync_writeback)) {
                        case PAGE_KEEP:
                                goto keep_locked;
                        case PAGE_ACTIVATE:
                                goto activate_locked;
                        case PAGE_SUCCESS:
                                if (PageWriteback(page) || PageDirty(page))
                                        goto keep;                                     ///////  HERE
---------------------------------------------------------------------------------------



> >   - vmscan maintain page granularity lru list. It mean vmscan makes awful
> >     seekful I/O. it assume block-layer buffered much i/o request.
> >   - plus, the above mena vmscan. writeout need good io throughput. otherwise
> >     system might cause hangup.
> > 
> > However, I don't think kswapd_awake is good choice. because
> >   - zone reclaim run before kswapd wakeup. iow, this patch doesn't solve hpc machine.
> >     btw, some Core i7 box (at least, Intel's reference box) also use zone reclaim.
> 
> Good point.
> 
> >   - On large (many memory node) machine, one of much kswapd always run.
> > 
> 
> Also true.
> 
> > 
> > Instead, PF_MEMALLOC is good idea?
> 
> It doesn't work out either because a process with PF_MEMALLOC is in
> direct reclaim and like kswapd, it may not be able to clean the pages at
> all, let alone in a small period of time.

please forget this idea ;)


--
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>

  reply	other threads:[~2009-11-30 10:18 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
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 [this message]
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=20091130190711.5BFF.A69D9226@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=czoccolo@gmail.com \
    --cc=elendil@planet.nl \
    --cc=jens.axboe@oracle.com \
    --cc=jkosina@suse.cz \
    --cc=karol.k.lewandowski@gmail.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