[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130424144130.0d28b94b229b915d7f9c7840@linux-foundation.org>
Date: Wed, 24 Apr 2013 14:41:30 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Theodore Ts'o" <tytso@....edu>
Cc: Hugh Dickins <hughd@...gle.com>,
Bernd Schubert <bernd.schubert@...tmail.fm>,
Alexey Lyahkov <alexey.lyashkov@...il.com>,
Will Huck <will.huckk@...il.com>,
Andrew Perepechko <anserper@...ru>, linux-ext4@...r.kernel.org,
linux-mm@...ck.org, mgorman@...e.de
Subject: Re: page eviction from the buddy cache
On Wed, 24 Apr 2013 10:26:50 -0400 "Theodore Ts'o" <tytso@....edu> wrote:
> On Tue, Apr 23, 2013 at 03:00:08PM -0700, Andrew Morton wrote:
> > That should fix things for now. Although it might be better to just do
> >
> > mark_page_accessed(page); /* to SetPageReferenced */
> > lru_add_drain(); /* to SetPageLRU */
> >
> > Because a) this was too early to decide that the page is
> > super-important and b) the second touch of this page should have a
> > mark_page_accessed() in it already.
>
> The question is do we really want to put lru_add_drain() into the ext4
> file system code? That seems to pushing some fairly mm-specific
> knowledge into file system code. I'll do this if I have to do, but
> wouldn't be better if this was pushed into mark_page_accessed(), or
> some other new API was exported by the mm subsystem?
Sure, that would be daft. We'd add a new
mark_page_accessed_right_now_dont_use_this() to mm/swap.c
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists