[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130319110648.GL2055@suse.de>
Date: Tue, 19 Mar 2013 11:06:48 +0000
From: Mel Gorman <mgorman@...e.de>
To: Andi Kleen <andi@...stfloor.org>
Cc: Linux-MM <linux-mm@...ck.org>, Jiri Slaby <jslaby@...e.cz>,
Valdis Kletnieks <Valdis.Kletnieks@...edu>,
Rik van Riel <riel@...hat.com>,
Zlatko Calusic <zcalusic@...sync.net>,
Johannes Weiner <hannes@...xchg.org>,
dormando <dormando@...ia.net>,
Satoru Moriya <satoru.moriya@....com>,
Michal Hocko <mhocko@...e.cz>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 07/10] mm: vmscan: Block kswapd if it is encountering
pages under writeback
On Sun, Mar 17, 2013 at 04:40:13PM +0100, Andi Kleen wrote:
> > > BTW longer term the code would probably be a lot clearer with a
> > > real explicit state machine instead of all these custom state bits.
> > >
> >
> > I would expect so even though it'd be a major overhawl.
>
> A lot of these VM paths need overhaul because they usually don't
> do enough page batching to perform really well on larger systems.
>
While I agree this is also a serious issue and one you brought up last year,
the issue here is that page reclaim is making bad decisions for ordinary
machines. The figures in the leader patch show that a single-threaded
background write is enough to push an active application into swap.
For reclaim, the batching that is meant to mitigate part of this problem
is page lruvecs but that has been causing its own problems recently. At
some point the bullet will have to be bitten by removing pagevecs, seeing
what falls out and then design and implement a better batching mechanism
for handling large numbers of struct pages.
--
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists