[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87k4k49jii.fsf@gmail.com>
Date: Tue, 23 Nov 2010 09:55:49 -0500
From: Ben Gamari <bgamari@...il.com>
To: Mel Gorman <mel@....ul.ie>,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Minchan Kim <minchan.kim@...il.com>, linux-mm <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Rik van Riel <riel@...hat.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Johannes Weiner <hannes@...xchg.org>,
Nick Piggin <npiggin@...nel.dk>
Subject: Re: [RFC 1/2] deactive invalidated pages
On Tue, 23 Nov 2010 09:38:59 +0000, Mel Gorman <mel@....ul.ie> wrote:
> > If it's mapped pagecache then the user was being a bit silly (or didn't
> > know that some other process had mapped the file). In which case we
> > need to decide what to do - leave the page alone, deactivate it, or
> > half-deactivate it as this patch does.
> >
>
> What are the odds of an fadvise() user having used mincore() in advance
> to determine if the page was in use by another process? I would guess
> "low" so this half-deactivate gives a chance for the page to be promoted
> again as well as a chance for the flusher threads to clean the page if
> it really is to be reclaimed.
>
Do we really want to make the user jump through such hoops as using
mincore() just to get the kernel to handle use-once pages properly?
I hope the answer is no. I know that fadvise isn't supposed to be a
magic bullet, but it would be nice if more processes would use it to
indicate their access patterns and the only way that will happen is if
it is reasonably straightforward to use.
- Ben
--
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