linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: Avi Kivity <avi@redhat.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>, kvm <kvm@vger.kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC/T/D][PATCH 2/2] Linux/Guest cooperative unmapped page cache control
Date: Mon, 14 Jun 2010 14:18:10 +0530	[thread overview]
Message-ID: <20100614084810.GT5191@balbir.in.ibm.com> (raw)
In-Reply-To: <4C15E3C8.20407@redhat.com>

* Avi Kivity <avi@redhat.com> [2010-06-14 11:09:44]:

> On 06/11/2010 07:56 AM, Balbir Singh wrote:
> >
> >>Just to be clear, let's say we have a mapped page (say of /sbin/init)
> >>that's been unreferenced since _just_ after the system booted.  We also
> >>have an unmapped page cache page of a file often used at runtime, say
> >>one from /etc/resolv.conf or /etc/passwd.
> >>
> >>Which page will be preferred for eviction with this patch set?
> >>
> >In this case the order is as follows
> >
> >1. First we pick free pages if any
> >2. If we don't have free pages, we go after unmapped page cache and
> >slab cache
> >3. If that fails as well, we go after regularly memory
> >
> >In the scenario that you describe, we'll not be able to easily free up
> >the frequently referenced page from /etc/*. The code will move on to
> >step 3 and do its regular reclaim.
> 
> Still it seems to me you are subverting the normal order of reclaim.
> I don't see why an unmapped page cache or slab cache item should be
> evicted before a mapped page.  Certainly the cost of rebuilding a
> dentry compared to the gain from evicting it, is much higher than
> that of reestablishing a mapped page.
>

Subverting to aviod memory duplication, the word subverting is
overloaded, let me try to reason a bit. First let me explain the
problem

Memory is a precious resource in a consolidated environment.
We don't want to waste memory via page cache duplication
(cache=writethrough and cache=writeback mode).

Now here is what we are trying to do

1. A slab page will not be freed until the entire page is free (all
slabs have been kfree'd so to speak). Normal reclaim will definitely
free this page, but a lot of it depends on how frequently we are
scanning the LRU list and when this page got added.
2. In the case of page cache (specifically unmapped page cache), there
is duplication already, so why not go after unmapped page caches when
the system is under memory pressure?

In the case of 1, we don't force a dentry to be freed, but rather a
freed page in the slab cache to be reclaimed ahead of forcing reclaim
of mapped pages.

Does the problem statement make sense? If so, do you agree with 1 and
2? Is there major concern about subverting regular reclaim? Does
subverting it make sense in the duplicated scenario?

-- 
	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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-06-14  8:48 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 15:51 [RFC/T/D][PATCH 0/2] KVM page cache optimization (v2) Balbir Singh
2010-06-08 15:51 ` [RFC][PATCH 1/2] Linux/Guest unmapped page cache control Balbir Singh
2010-06-13 18:31   ` Balbir Singh
2010-06-14  0:28     ` KAMEZAWA Hiroyuki
2010-06-14  6:49       ` Balbir Singh
2010-06-14  7:00         ` KAMEZAWA Hiroyuki
2010-06-14  7:36           ` Balbir Singh
2010-06-14  7:49             ` KAMEZAWA Hiroyuki
2010-06-08 15:51 ` [RFC/T/D][PATCH 2/2] Linux/Guest cooperative " Balbir Singh
2010-06-10  9:43   ` Avi Kivity
2010-06-10 14:25     ` Balbir Singh
2010-06-11  0:07       ` Dave Hansen
2010-06-11  1:54         ` KAMEZAWA Hiroyuki
2010-06-11  4:46           ` Balbir Singh
2010-06-11  5:05             ` KAMEZAWA Hiroyuki
2010-06-11  5:08               ` KAMEZAWA Hiroyuki
2010-06-11  6:14               ` Balbir Singh
2010-06-11  4:56         ` Balbir Singh
2010-06-14  8:09           ` Avi Kivity
2010-06-14  8:48             ` Balbir Singh [this message]
2010-06-14 12:40               ` Avi Kivity
2010-06-14 12:50                 ` Balbir Singh
2010-06-14 13:01                   ` Avi Kivity
2010-06-14 15:33                     ` Dave Hansen
2010-06-14 15:44                       ` Avi Kivity
2010-06-14 15:55                         ` Dave Hansen
2010-06-14 16:34                           ` Avi Kivity
2010-06-14 17:45                             ` Balbir Singh
2010-06-15  6:58                               ` Avi Kivity
2010-06-15  7:49                                 ` Balbir Singh
2010-06-15  9:44                                   ` Avi Kivity
2010-06-15 10:18                                     ` Balbir Singh
2010-06-14 17:58                             ` Dave Hansen
2010-06-15  7:07                               ` Avi Kivity
2010-06-15 14:47                                 ` Dave Hansen
2010-06-16 11:39                                   ` Avi Kivity
2010-06-17  6:04                                     ` Balbir Singh
2010-06-14 15:12               ` Dave Hansen
2010-06-14 15:34                 ` Avi Kivity
2010-06-14 17:40                   ` Balbir Singh
2010-06-15  7:11                     ` Avi Kivity
2010-06-14 16:58                 ` Balbir Singh
2010-06-14 17:09                   ` Dave Hansen
2010-06-14 17:16                     ` Balbir Singh
2010-06-15  7:12                       ` Avi Kivity
2010-06-15  7:52                         ` Balbir Singh
2010-06-15  9:54                           ` Avi Kivity
2010-06-15 12:49                             ` Balbir Singh

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=20100614084810.GT5191@balbir.in.ibm.com \
    --to=balbir@linux.vnet.ibm.com \
    --cc=avi@redhat.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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