public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: balbir@linux.vnet.ibm.com
Cc: jdike@addtoit.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, avi@redhat.com,
	aarcange@redhat.com, mtosatti@redhat.com
Subject: Re: [PATCH] emulate accessed bit for EPT
Date: Thu, 04 Feb 2010 10:41:14 -0500	[thread overview]
Message-ID: <4B6AEA9A.90704@redhat.com> (raw)
In-Reply-To: <20100204153013.GK19641@balbir.in.ibm.com>

Balbir Singh wrote:
> * Rik van Riel <riel@redhat.com> [2010-02-04 08:40:43]:
> 
>> On 02/03/2010 11:12 PM, Balbir Singh wrote:
>>> * Rik van Riel<riel@redhat.com>  [2010-02-03 16:11:03]:
>>>
>>>> Currently KVM pretends that pages with EPT mappings never got
>>>> accessed.  This has some side effects in the VM, like swapping
>>>> out actively used guest pages and needlessly breaking up actively
>>>> used hugepages.
>>>>
>>>> We can avoid those very costly side effects by emulating the
>>>> accessed bit for EPT PTEs, which should only be slightly costly
>>>> because pages pass through page_referenced infrequently.
>>> Quite a clever implementation, one side effect is that one would see a
>>> larger number of minor faults with EPT enabled and an increase in
>>> allocation/frees of rmap entries, but that can be easily explained.
>> I suspect it won't be very many. I have been monitoring
>> /proc/meminfo on my system while testing this patch, and
>> it is quite typical that the size of the inactive anon
>> list does not change for minutes at a time.
>>
>> In other words, no pages are moved onto or off of the
>> inactive anon list for several minutes. That corresponds
>> to a very small number of minor faults introduced by my
>> patch.
>>
>> Of course, when the system is swapping, we will have more
>> minor faults.  However, minor faults should be less of a
>> performance issue than major faults :)
>>
> 
> I do agree with you. 

After 20 hours of uptime, it appears that this patch has
resolved the "KVM guests get swapped while buffer and page
cache stay in memory" problem my home system was experiencing.

  reply	other threads:[~2010-02-04 15:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-03 21:11 [PATCH] emulate accessed bit for EPT Rik van Riel
2010-02-04  4:12 ` Balbir Singh
2010-02-04 13:40   ` Rik van Riel
2010-02-04 15:30     ` Balbir Singh
2010-02-04 15:41       ` Rik van Riel [this message]
2010-02-04 15:52         ` Balbir Singh
2010-02-04 17:47     ` Andrea Arcangeli
2010-02-05 17:34       ` Marcelo Tosatti
2010-02-05 18:14         ` Andrea Arcangeli
2010-02-07 19:21           ` Marcelo Tosatti
2010-02-04 16:17 ` Jeff Dike
2010-02-08 10:27 ` Avi Kivity

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=4B6AEA9A.90704@redhat.com \
    --to=riel@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=avi@redhat.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=jdike@addtoit.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@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