linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: linux-mm <linux-mm@kvack.org>
Cc: kvm@vger.kernel.org, Hugh Dickins <hughd@google.com>,
	KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	Minchan Kim <minchan@kernel.org>
Subject: pci device assignment and mm, KSM.
Date: Wed, 04 Jul 2012 15:16:37 +0900	[thread overview]
Message-ID: <4FF3DFC5.2010409@jp.fujitsu.com> (raw)


I'm sorry if my understanding is incorrect. Here are some topics on
pci passthrough to guests.

When pci passthrough is used with kvm, guest's all memory are pinned by extra
reference count of get_page(). That pinned pages are never be reclaimable and
movable by migration and cannot be merged by KSM.

Now, the information that 'the page is pinned by kvm' is just represented by
page_count(). So, there are following problems.

a) pages are on ANON_LRU. So, try_to_free_page() and kswapd will scan XX GB of
   pages hopelessly.

b) KSM cannot recognize the pages in its early stage. So, it breaks transparent
   huge page mapped by kvm into small pages. But it fails to merge them finally,
   because of raised page_count(). So, all hugepages are split without any
   benefits.

2 ideas for fixing this....

for a) I guess the pages should go to UNEVICTABLE list. But it's not mlocked.
       I think we use PagePinned() instread of it and move pages to UNEVICTABLE list.
       Then, kswapd etc will ignore pinned pages.

for b) At first, I thought qemu should call madvise(MADV_UNMERGEABLE). But I think
       kernel may be able to handle situation with an extra check, PagePinned() or
       checking a flag in mm_struct. Should we avoid this in userland or kernel ?

BTW, I think pinned pages cannot be freed until the kvm process exits. Is it right ?

Thanks,
-Kame

--
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:[~2012-07-04  6:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4FF3DFC5.2010409@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.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