From: Mel Gorman <mgorman@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: Alexey Lyahkov <alexey.lyashkov@gmail.com>,
Andrew Perepechko <anserper@ya.ru>,
Robin Dong <sanbai@taobao.com>, Theodore Tso <tytso@mit.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Bernd Schubert <bernd.schubert@fastmail.fm>,
David Howells <dhowells@redhat.com>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
Linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux-ext4 <linux-ext4@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 1/3] mm: pagevec: Defer deciding what LRU to add a page to until pagevec drain time
Date: Fri, 3 May 2013 09:37:49 +0100 [thread overview]
Message-ID: <20130503083749.GL11497@suse.de> (raw)
In-Reply-To: <20130503075158.GB10633@quack.suse.cz>
On Fri, May 03, 2013 at 09:51:58AM +0200, Jan Kara wrote:
> > @@ -789,17 +787,16 @@ void lru_add_page_tail(struct page *page, struct page *page_tail,
> > static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
> > void *arg)
> > {
> > - enum lru_list lru = (enum lru_list)arg;
> > - int file = is_file_lru(lru);
> > - int active = is_active_lru(lru);
> > + enum lru_list requested_lru = (enum lru_list)arg;
> > + int file = page_is_file_cache(page);
> > + int active = PageActive(page);
> > + enum lru_list lru = page_lru(page);
> >
> > - VM_BUG_ON(PageActive(page));
> > + WARN_ON_ONCE(requested_lru < NR_LRU_LISTS && requested_lru != lru);
> Hum, so __lru_cache_add() calls this with 'requested_lru' set to whatever
> LRU we currently want to add a page. How should this always be equal to the
> LRU of all the pages we have cached in the pagevec?
>
It wouldn't necessarily be and and for a pagevec drain, it's ignored
completely.
> And if I'm right, there doesn't seem to be a reason to pass requested_lru
> to this function at all, does it?
>
You've already noticed that it gets thrown away later in the third
patch. It was left in this patch as a debugging aid in case there was a
direct pagevec user that expected to place pages on an LRU that was at
odds with the page flags.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mgorman@suse.de>
To: Jan Kara <jack@suse.cz>
Cc: Alexey Lyahkov <alexey.lyashkov@gmail.com>,
Andrew Perepechko <anserper@ya.ru>,
Robin Dong <sanbai@taobao.com>, Theodore Tso <tytso@mit.edu>,
Andrew Morton <akpm@linux-foundation.org>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Bernd Schubert <bernd.schubert@fastmail.fm>,
David Howells <dhowells@redhat.com>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
Linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux-ext4 <linux-ext4@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 1/3] mm: pagevec: Defer deciding what LRU to add a page to until pagevec drain time
Date: Fri, 3 May 2013 09:37:49 +0100 [thread overview]
Message-ID: <20130503083749.GL11497@suse.de> (raw)
In-Reply-To: <20130503075158.GB10633@quack.suse.cz>
On Fri, May 03, 2013 at 09:51:58AM +0200, Jan Kara wrote:
> > @@ -789,17 +787,16 @@ void lru_add_page_tail(struct page *page, struct page *page_tail,
> > static void __pagevec_lru_add_fn(struct page *page, struct lruvec *lruvec,
> > void *arg)
> > {
> > - enum lru_list lru = (enum lru_list)arg;
> > - int file = is_file_lru(lru);
> > - int active = is_active_lru(lru);
> > + enum lru_list requested_lru = (enum lru_list)arg;
> > + int file = page_is_file_cache(page);
> > + int active = PageActive(page);
> > + enum lru_list lru = page_lru(page);
> >
> > - VM_BUG_ON(PageActive(page));
> > + WARN_ON_ONCE(requested_lru < NR_LRU_LISTS && requested_lru != lru);
> Hum, so __lru_cache_add() calls this with 'requested_lru' set to whatever
> LRU we currently want to add a page. How should this always be equal to the
> LRU of all the pages we have cached in the pagevec?
>
It wouldn't necessarily be and and for a pagevec drain, it's ignored
completely.
> And if I'm right, there doesn't seem to be a reason to pass requested_lru
> to this function at all, does it?
>
You've already noticed that it gets thrown away later in the third
patch. It was left in this patch as a debugging aid in case there was a
direct pagevec user that expected to place pages on an LRU that was at
odds with the page flags.
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2013-05-03 8:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-29 16:31 [RFC PATCH 0/3] Obey mark_page_accessed hint given by filesystems Mel Gorman
2013-04-29 16:31 ` Mel Gorman
2013-04-29 16:31 ` [PATCH 1/3] mm: pagevec: Defer deciding what LRU to add a page to until pagevec drain time Mel Gorman
2013-04-29 16:31 ` Mel Gorman
2013-04-29 16:50 ` Rik van Riel
2013-04-29 16:50 ` Rik van Riel
2013-05-03 7:51 ` Jan Kara
2013-05-03 7:51 ` Jan Kara
2013-05-03 8:37 ` Mel Gorman [this message]
2013-05-03 8:37 ` Mel Gorman
2013-04-29 16:31 ` [PATCH 2/3] mm: Ensure that mark_page_accessed moves pages to the active list Mel Gorman
2013-04-29 16:31 ` Mel Gorman
2013-04-29 17:12 ` Rik van Riel
2013-04-29 17:12 ` Rik van Riel
2013-04-29 21:53 ` Mel Gorman
2013-04-29 21:53 ` Mel Gorman
2013-05-01 5:41 ` Sam Ben
2013-05-01 5:41 ` Sam Ben
2013-05-01 8:06 ` Mel Gorman
2013-05-01 8:06 ` Mel Gorman
2013-05-01 8:14 ` Ric Mason
2013-05-01 8:14 ` Ric Mason
2013-05-01 8:31 ` Mel Gorman
2013-05-01 8:31 ` Mel Gorman
2013-04-29 16:31 ` [PATCH 3/3] mm: Remove lru parameter from __pagevec_lru_add and remove parts of pagevec API Mel Gorman
2013-04-29 16:31 ` Mel Gorman
2013-05-03 8:00 ` Jan Kara
2013-05-03 8:00 ` Jan Kara
2013-05-01 6:28 ` [RFC PATCH 0/3] Obey mark_page_accessed hint given by filesystems Will Huck
2013-05-01 6:28 ` Will Huck
2013-05-01 8:08 ` Mel Gorman
2013-05-01 8:08 ` Mel Gorman
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=20130503083749.GL11497@suse.de \
--to=mgorman@suse.de \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=alexey.lyashkov@gmail.com \
--cc=anserper@ya.ru \
--cc=bernd.schubert@fastmail.fm \
--cc=dhowells@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=sanbai@taobao.com \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.