From: Josh Zhao <joshsystem@gmail.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>,
Bob Liu <bob.liu@oracle.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH] xen/tmem: Don't use map_domain_page for long-life-time pages.
Date: Thu, 22 Aug 2013 18:28:05 +0800 [thread overview]
Message-ID: <CAOYkbagV8sDvLqxJGo81-HoRBVS8FUZ0w2-nW_w1BNiwWJOZPw@mail.gmail.com> (raw)
In-Reply-To: <20130613132909.GI6303@konrad-lan.dumpdata.com>
2013/6/13 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>:
> On Thu, Jun 13, 2013 at 02:24:11PM +0100, George Dunlap wrote:
>> On 13/06/13 13:50, Konrad Rzeszutek Wilk wrote:
>> >When using tmem with Xen 4.3 (and debug build) we end up with:
>> >
>> >(XEN) Xen BUG at domain_page.c:143
>> >(XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]----
>> >(XEN) CPU: 3
>> >(XEN) RIP: e008:[<ffff82c4c01606a7>] map_domain_page+0x61d/0x6e1
>> >..
>> >(XEN) Xen call trace:
>> >(XEN) [<ffff82c4c01606a7>] map_domain_page+0x61d/0x6e1
>> >(XEN) [<ffff82c4c01373de>] cli_get_page+0x15e/0x17b
>> >(XEN) [<ffff82c4c01377c4>] tmh_copy_from_client+0x150/0x284
>> >(XEN) [<ffff82c4c0135929>] do_tmem_put+0x323/0x5c4
>> >(XEN) [<ffff82c4c0136510>] do_tmem_op+0x5a0/0xbd0
>> >(XEN) [<ffff82c4c022391b>] syscall_enter+0xeb/0x145
>> >(XEN)
>> >
>> >A bit of debugging revealed that the map_domain_page and unmap_domain_page
>> >are meant for short life-time mappings. And that those mappings are finite.
>> >In the 2 VCPU guest we only have 32 entries and once we have exhausted those
>> >we trigger the BUG_ON condition.
>> >
>> >The two functions - tmh_persistent_pool_page_[get,put] are used by the xmem_pool
>> >when xmem_pool_[alloc,free] are called. These xmem_pool_* function are wrapped
>> >in macro and functions - the entry points are via: tmem_malloc
>> >and tmem_page_alloc. In both cases the users are in the hypervisor and they
>> >do not seem to suffer from using the hypervisor virtual addresses.
>> >
>> >CC: Bob Liu <bob.liu@oracle.com>
>> >CC: Dan Magenheimer <dan.magenheimer@oracle.com>
>> >Suggested-by: Jan Beulich <jbeulich@suse.com>
>> >Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>> >---
>> > xen/common/tmem_xen.c | 5 ++---
>> > 1 files changed, 2 insertions(+), 3 deletions(-)
>> >
>> >diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
>> >index 3a1f3c9..736a8c3 100644
>> >--- a/xen/common/tmem_xen.c
>> >+++ b/xen/common/tmem_xen.c
>> >@@ -385,7 +385,7 @@ static void *tmh_persistent_pool_page_get(unsigned long size)
>> > if ( (pi = _tmh_alloc_page_thispool(d)) == NULL )
>> > return NULL;
>> > ASSERT(IS_VALID_PAGE(pi));
>> >- return __map_domain_page(pi);
>> >+ return page_to_virt(pi);
>>
>> Did I understand correctly that the map_domain_page() was required
>> on >5TiB systems, presumably because of limited virtual address
>> space? In which case this code will fail on those systems?
>
> Correct.
I don't understand why the map_domain_page() was required on >5TiB ?
>>
>> If that is the case, then we need to have a way to make sure tmem
>> cannot be enabled on such systems.
>
> Which Jan has had already done when he posted the 5TB patches.
>
>>
>> -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2013-08-22 10:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 12:50 [PATCH] xen/tmem: Don't use map_domain_page for long-life-time pages Konrad Rzeszutek Wilk
2013-06-13 13:24 ` George Dunlap
2013-06-13 13:29 ` Konrad Rzeszutek Wilk
2013-08-22 10:15 ` Josh Zhao
2013-08-22 10:27 ` Ian Campbell
2013-08-22 10:28 ` Josh Zhao [this message]
2013-06-13 13:40 ` Ian Campbell
2013-06-13 13:49 ` Jan Beulich
2013-06-13 13:55 ` Ian Campbell
2013-06-13 13:56 ` George Dunlap
2013-06-13 14:04 ` Jan Beulich
2013-06-13 14:10 ` Ian Campbell
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=CAOYkbagV8sDvLqxJGo81-HoRBVS8FUZ0w2-nW_w1BNiwWJOZPw@mail.gmail.com \
--to=joshsystem@gmail.com \
--cc=bob.liu@oracle.com \
--cc=jbeulich@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=konrad@kernel.org \
--cc=xen-devel@lists.xensource.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).