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
WARNING: multiple messages have this Message-ID (diff)
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>
next reply other threads:[~2012-07-04 6:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-04 6:16 Kamezawa Hiroyuki [this message]
2012-07-04 6:16 ` pci device assignment and mm, KSM Kamezawa Hiroyuki
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 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.