[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100526102330.GL29038@csn.ul.ie>
Date: Wed, 26 May 2010 11:23:30 +0100
From: Mel Gorman <mel@....ul.ie>
To: Johannes Weiner <hannes@...xchg.org>
Cc: linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Chris Mason <chris.mason@...cle.com>,
Dave Chinner <david@...morbit.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH 02/10] vmscan: move priority variable into scan_control
Sorry for the long delay on this. I got distracted by the anon_vma and
page migration stuff.
On Sat, Apr 17, 2010 at 12:48:20AM +0200, Johannes Weiner wrote:
> On Thu, Apr 15, 2010 at 06:21:35PM +0100, Mel Gorman wrote:
> > From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> >
> > Now very lots function in vmscan have `priority' argument. It consume
> > stack slightly. To move it on struct scan_control reduce stack.
>
> I don't like this much because it obfuscates value communication.
>
> Functions no longer have obvious arguments and return values, as it's all
> passed hidden in that struct.
>
> Do you think it's worth it? I would much rather see that thing die than
> expand on it...
I don't feel strongly enough to fight about it and reducing stack usage here
isn't the "fix" anyway. I'll drop this patch for now.
That aside, the page reclaim algorithm maintains a lot of state and the
"priority" is part of that state. While the struct means that functions might
not have obvious arguments, passing the state around as arguments gets very
unwieldly very quickly. I don't think killing scan_control would be as
nice as you imagine although I do think it should be as small as
possible.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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