From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andrew Morton <akpm@osdl.org>
Cc: wfg@mail.ustc.edu.cn, linux-kernel@vger.kernel.org,
christoph@lameter.com, riel@redhat.com, a.p.zijlstra@chello.nl,
npiggin@suse.de, andrea@suse.de, magnus.damm@gmail.com
Subject: Re: [PATCH 02/12] mm: supporting variables and functions for balanced zone aging
Date: Thu, 1 Dec 2005 23:26:45 -0200 [thread overview]
Message-ID: <20051202012645.GA3834@dmt.cnet> (raw)
In-Reply-To: <20051201150349.3538638e.akpm@osdl.org>
On Thu, Dec 01, 2005 at 03:03:49PM -0800, Andrew Morton wrote:
> Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
> >
> > Hi Andrew,
> >
> > On Thu, Dec 01, 2005 at 02:37:14AM -0800, Andrew Morton wrote:
> > > Wu Fengguang <wfg@mail.ustc.edu.cn> wrote:
> > > >
> > > > The zone aging rates are currently imbalanced,
> > >
> > > ZONE_DMA is out of whack. It shouldn't be, and I'm not aware of anyone
> > > getting in and working out why. I certainly wouldn't want to go and add
> > > all this stuff without having a good understanding of _why_ it's out of
> > > whack. Perhaps it's just some silly bug, like the thing I pointed at in
> > > the previous email.
> >
> > I think that the problem is caused by the interaction between
> > the way reclaiming is quantified and parallel allocators.
>
> Could be. But what about the bug which I think is there? That'll cause
> overscanning of the DMA zone.
There were about 12Mb of inactive pages on the DMA zone. You're hypothesis
was that there were no LRU pages to be scanned on DMA zone?
> > The zones have different sizes, and each zone reclaim iteration
> > scans the same number of pages. It is unfair.
>
> Nope. See how shrink_zone() bases nr_active and nr_inactive on
> zone->nr_active and zone_nr_inactive. These calculations are intended to
> cause the number of scanned pages in each zone to be
>
> (zone->nr-active + zone->nr_inactive) >> sc->priority.
True... Well, I don't know, then.
> > On top of that, kswapd is likely to block while doing its job,
> > which means that allocators have a chance to run.
>
> kswapd should only block under rare circumstances - huge amounts of dirty
> pages coming off the tail of the LRU.
Alright. I don't know - what could be the problem, then?
> > --- mm/vmscan.c.orig 2006-01-01 12:44:39.000000000 -0200
> > +++ mm/vmscan.c 2006-01-01 16:43:54.000000000 -0200
> > @@ -616,8 +616,12 @@
> > {
>
> Please use `diff -p'.
next prev parent reply other threads:[~2005-12-02 3:05 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-01 10:18 [PATCH 00/12] Balancing the scan rate of major caches Wu Fengguang
2005-12-01 10:18 ` [PATCH 01/12] vm: kswapd incmin Wu Fengguang
2005-12-01 10:33 ` Andrew Morton
2005-12-01 11:40 ` Wu Fengguang
2005-12-01 10:18 ` [PATCH 02/12] mm: supporting variables and functions for balanced zone aging Wu Fengguang
2005-12-01 10:37 ` Andrew Morton
2005-12-01 12:11 ` Wu Fengguang
2005-12-01 22:28 ` Marcelo Tosatti
2005-12-01 23:03 ` Andrew Morton
2005-12-02 1:19 ` Wu Fengguang
2005-12-02 1:30 ` Andrew Morton
2005-12-02 2:04 ` Wu Fengguang
2005-12-02 2:18 ` Andrea Arcangeli
2005-12-02 2:37 ` Wu Fengguang
2005-12-02 2:52 ` Andrea Arcangeli
2005-12-02 4:45 ` Andrew Morton
2005-12-02 6:38 ` Wu Fengguang
2005-12-02 2:27 ` Nick Piggin
2005-12-02 2:36 ` Andrea Arcangeli
2005-12-02 2:43 ` Wu Fengguang
2005-12-02 5:49 ` Andrew Morton
2005-12-02 7:18 ` Wu Fengguang
2005-12-02 7:27 ` Andrew Morton
2005-12-02 15:13 ` Marcelo Tosatti
2005-12-02 21:39 ` Andrew Morton
2005-12-03 0:26 ` Marcelo Tosatti
2005-12-04 6:06 ` Wu Fengguang
2005-12-02 1:26 ` Marcelo Tosatti [this message]
2005-12-02 3:40 ` Andrew Morton
2005-12-01 10:18 ` [PATCH 03/12] mm: balance zone aging in direct reclaim path Wu Fengguang
2005-12-01 10:18 ` [PATCH 04/12] mm: balance zone aging in kswapd " Wu Fengguang
2005-12-01 10:18 ` [PATCH 05/12] mm: balance slab aging Wu Fengguang
2005-12-01 10:18 ` [PATCH 06/12] mm: balance active/inactive list scan rates Wu Fengguang
2005-12-01 11:39 ` Peter Zijlstra
2005-12-01 10:18 ` [PATCH 07/12] mm: remove unnecessary variable and loop Wu Fengguang
2005-12-01 10:18 ` [PATCH 08/12] mm: remove swap_cluster_max from scan_control Wu Fengguang
2005-12-01 10:18 ` [PATCH 09/12] mm: accumulate sc.nr_scanned/sc.nr_reclaimed Wu Fengguang
2005-12-01 10:18 ` [PATCH 10/12] mm: merge sc.may_writepage and sc.may_swap into sc.flags Wu Fengguang
2005-12-01 10:18 ` [PATCH 11/12] mm: add page reclaim debug traces Wu Fengguang
2005-12-01 10:18 ` [PATCH 12/12] mm: fix minor scan count bugs Wu Fengguang
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=20051202012645.GA3834@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=christoph@lameter.com \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=npiggin@suse.de \
--cc=riel@redhat.com \
--cc=wfg@mail.ustc.edu.cn \
/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