From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Wu Fengguang <fengguang.wu@intel.com>,
Nick Piggin <npiggin@kernel.dk>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH v4 2/7] deactivate invalidated pages
Date: Wed, 8 Dec 2010 12:26:50 +0530 [thread overview]
Message-ID: <20101208065650.GP3158@balbir.in.ibm.com> (raw)
In-Reply-To: <AANLkTim9to0Wa_iWyVA4FSV6sfT4tcR2bmV7t54HOQ1c@mail.gmail.com>
* MinChan Kim <minchan.kim@gmail.com> [2010-12-08 11:15:19]:
> On Wed, Dec 8, 2010 at 10:56 AM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > On Wed, 8 Dec 2010 10:43:08 +0900
> > Minchan Kim <minchan.kim@gmail.com> wrote:
> >
> >> Hi Kame,
> >>
> > Hi,
> >
> >> > I wonder ...how about adding "victim" list for "Reclaim" pages ? Then, we don't need
> >> > extra LRU rotation.
> >>
> >> It can make the code clean.
> >> As far as I think, victim list does following as.
> >>
> >> 1. select victim pages by strong hint
> >> 2. move the page from LRU to victim
> >> 3. reclaimer always peeks victim list before diving into LRU list.
> >> 4-1. If the victim pages is used by others or dirty, it can be moved
> >> into LRU, again or remain the page in victim list.
> >> If the page is remained victim, when do we move it into LRU again if
> >> the reclaimer continues to fail the page?
> > When sometone touches it.
> >
> >> We have to put the new rule.
> >> 4-2. If the victim pages isn't used by others and clean, we can
> >> reclaim the page asap.
> >>
> >> AFAIK, strong hints are just two(invalidation, readahead max window heuristic).
> >> I am not sure it's valuable to add new hierarchy(ie, LRU, victim,
> >> unevictable) for cleaning the minor codes.
> >> In addition, we have to put the new rule so it would make the LRU code
> >> complicated.
> >> I remember how unevictable feature merge is hard.
> >>
> > yes, it was hard.
> >
> >> But I am not against if we have more usecases. In this case, it's
> >> valuable to implement it although it's not easy.
> >>
> >
> > I wonder "victim list" can be used for something like Cleancache, when
> > we have very-low-latency backend devices.
> > And we may able to have page-cache-limit, which Balbir proposed as.
>
> Yes, I thought that, too. I think it would be a good feature in embedded system.
>
> >
> > - kvictimed? will move unmappedd page caches to victim list
> > This may work like a InactiveClean list which we had before and make
> > sizing easy.
> >
>
> Before further discuss, we need customer's confirm.
> We know very well it is very hard to merge if anyone doesn't use.
>
> Balbir, What do think about it?
>
The idea seems interesting, I am in the process of refreshing my
patches for unmapped page cache control. I presume the process of
filling the victim list will be similar to what I have or unmapped
page cache isolation.
>
> > Thanks,
> > -Kame
> >
> >
> >
> >
>
>
>
> --
> Kind regards,
> Minchan Kim
--
Three Cheers,
Balbir
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-12-08 6:57 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-05 17:29 [PATCH v4 0/7] f/madivse(DONTNEED) support Minchan Kim
2010-12-05 17:29 ` [PATCH v4 1/7] Fix checkpatch's report in swap.c Minchan Kim
2010-12-06 1:47 ` Rik van Riel
2010-12-07 14:37 ` Johannes Weiner
2010-12-05 17:29 ` [PATCH v4 2/7] deactivate invalidated pages Minchan Kim
2010-12-06 14:53 ` Mel Gorman
2010-12-07 14:49 ` Johannes Weiner
2010-12-07 15:07 ` Minchan Kim
2010-12-07 15:19 ` Johannes Weiner
2010-12-07 15:26 ` Minchan Kim
2010-12-07 15:56 ` Johannes Weiner
2010-12-07 22:51 ` Minchan Kim
2010-12-08 0:56 ` KAMEZAWA Hiroyuki
2010-12-08 1:43 ` Minchan Kim
2010-12-08 1:56 ` KAMEZAWA Hiroyuki
2010-12-08 2:15 ` Minchan Kim
2010-12-08 6:56 ` Balbir Singh [this message]
2010-12-09 0:19 ` Minchan Kim
2010-12-05 17:29 ` [PATCH v4 3/7] move memcg reclaimable page into tail of inactive list Minchan Kim
2010-12-06 0:04 ` KAMEZAWA Hiroyuki
2010-12-06 3:04 ` Rik van Riel
2010-12-07 0:17 ` Minchan Kim
2010-12-06 3:34 ` Balbir Singh
2010-12-07 0:20 ` Minchan Kim
2010-12-07 14:52 ` Johannes Weiner
2010-12-08 8:08 ` KOSAKI Motohiro
2010-12-05 17:29 ` [PATCH v4 4/7] Reclaim invalidated page ASAP Minchan Kim
2010-12-07 15:05 ` Johannes Weiner
2010-12-07 15:21 ` Minchan Kim
2010-12-08 8:04 ` KOSAKI Motohiro
2010-12-08 8:16 ` Minchan Kim
2010-12-08 13:01 ` Ben Gamari
2010-12-08 23:10 ` Minchan Kim
2010-12-13 15:31 ` Minchan Kim
2010-12-13 20:06 ` Ben Gamari
2010-12-14 2:36 ` Minchan Kim
2011-07-25 3:08 ` Ben Gamari
2011-07-25 3:47 ` Minchan Kim
2010-12-14 2:07 ` KAMEZAWA Hiroyuki
2010-12-14 2:34 ` Minchan Kim
2010-12-05 17:29 ` [PATCH v4 5/7] add profile information for invalidated page reclaim Minchan Kim
2010-12-06 3:24 ` Rik van Riel
2010-12-08 8:02 ` KOSAKI Motohiro
2010-12-08 8:13 ` Minchan Kim
2010-12-08 8:36 ` KOSAKI Motohiro
2010-12-05 17:29 ` [PATCH v4 6/7] Remove zap_details NULL dependency Minchan Kim
2010-12-06 3:25 ` Rik van Riel
2010-12-07 4:26 ` Hugh Dickins
2010-12-07 5:30 ` Minchan Kim
2010-12-05 17:29 ` [PATCH v4 7/7] Prevent activation of page in madvise_dontneed Minchan Kim
2010-12-07 4:48 ` Hugh Dickins
2010-12-07 5:44 ` Minchan Kim
2010-12-08 7:26 ` Hugh Dickins
2010-12-08 7:55 ` Minchan Kim
[not found] ` <AANLkTim71krrCcmhTTCZTzxeUDkvOdBTOkeYQu6EXt32@mail.gmail.com>
2010-12-07 1:52 ` [PATCH v4 0/7] f/madivse(DONTNEED) support Ben Gamari
2010-12-07 2:16 ` Minchan Kim
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=20101208065650.GP3158@balbir.in.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=hannes@cmpxchg.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=npiggin@kernel.dk \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).