From: Tamas K Lengyel <tamas.lengyel@zentific.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v7] x86/mem-sharing: mem-sharing a range of memory
Date: Tue, 19 Jul 2016 10:27:37 -0600 [thread overview]
Message-ID: <CAErYnsiPm4VkrC_9VzCNCyB7SN9yYQ6S+hH3o_BjmGcV_6PotA@mail.gmail.com> (raw)
In-Reply-To: <f08d9730-9a35-36e6-2552-f4022653463f@citrix.com>
On Mon, Jul 18, 2016 at 3:47 PM, Andrew Cooper
<andrew.cooper3@citrix.com> wrote:
> On 18/07/2016 22:14, Tamas K Lengyel wrote:
>> Currently mem-sharing can be performed on a page-by-page basis from the control
>> domain. However, this process is quite wasteful when a range of pages have to
>> be deduplicated.
>>
>> This patch introduces a new mem_sharing memop for range sharing where
>> the user doesn't have to separately nominate each page in both the source and
>> destination domain, and the looping over all pages happen in the hypervisor.
>> This significantly reduces the overhead of sharing a range of memory.
>>
>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
>> Acked-by: Wei Liu <wei.liu2@citrix.com>
>
> Some style nits, and one functional suggestion.
>
> If you are happy with the suggestion, then Reviewed-by: Andrew Cooper
> <andrew.cooper3@citrix.com>
Thanks!
>
>> diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
>> index a522423..6d00228 100644
>> --- a/xen/arch/x86/mm/mem_sharing.c
>> +++ b/xen/arch/x86/mm/mem_sharing.c
>> @@ -1294,6 +1294,58 @@ int relinquish_shared_pages(struct domain *d)
>> return rc;
>> }
>>
>> +static int range_share(struct domain *d, struct domain *cd,
>> + struct mem_sharing_op_range *range)
>
> Alignment.
>
>> +{
>> + int rc = 0;
>> + shr_handle_t sh, ch;
>> + unsigned long start =
>> + range->_scratchspace ? range->_scratchspace : range->start;
>
> This can be shortened to "unsigned long start = range->_scratchspace ?:
> range->start;" and fit on a single line.
I'm not that familiar with this style of the syntax, does that have
the effect of setting start = _scratchspace when _scratchspace is not
0?
>
>> +
>> + while( range->end >= start )
>> + {
>> + /*
>> + * We only break out if we run out of memory as individual pages may
>> + * legitimately be unsharable and we just want to skip over those.
>> + */
>> + rc = mem_sharing_nominate_page(d, start, 0, &sh);
>> + if ( rc == -ENOMEM )
>> + break;
>
> Newline here please
>
>> + if ( !rc )
>> + {
>> + rc = mem_sharing_nominate_page(cd, start, 0, &ch);
>> + if ( rc == -ENOMEM )
>> + break;
>
> And here.
>
>> + if ( !rc )
>> + {
>> + /* If we get here this should be guaranteed to succeed. */
>> + rc = mem_sharing_share_pages(d, start, sh,
>> + cd, start, ch);
>> + ASSERT(!rc);
>> + }
>> + }
>> +
>> + /* Check for continuation if it's not the last iteration. */
>> + if ( range->end >= ++start && hypercall_preempt_check() )
>> + {
>> + rc = 1;
>> + break;
>> + }
>> + }
>> +
>> + range->_scratchspace = start;
>> +
>> + /*
>> + * We only propagate -ENOMEM as individual pages may fail with -EINVAL,
>> + * and for range sharing we only care if -ENOMEM was encountered so we reset
>> + * rc here.
>> + */
>> + if ( rc < 0 && rc != -ENOMEM )
>
> Would you mind putting in an ASSERT(rc == -EINVAL) here, if we believe
> that to be an ok case to ignore? In the future if more errors get
> raised, we don't want to silently lose a more serious error which should
> be propagated up.
Well, in that case I can just change the if statement to rc == -EINVAL.
>
>> + rc = 0;
>> +
>> + return rc;
>> +}
>> +
>> int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>> {
>> int rc;
>> @@ -1468,6 +1520,94 @@ int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
>> }
>> break;
>>
>> + case XENMEM_sharing_op_range_share:
>> + {
>> + unsigned long max_sgfn, max_cgfn;
>> + struct domain *cd;
>> +
>> + rc = -EINVAL;
>> + if( mso.u.range._pad[0] || mso.u.range._pad[1] ||
>> + mso.u.range._pad[2] )
>> + goto out;
>> +
>> + /*
>> + * We use _scratchscape for the hypercall continuation value.
>> + * Ideally the user sets this to 0 in the beginning but
>> + * there is no good way of enforcing that here, so we just check
>> + * that it's at least in range.
>> + */
>> + if ( mso.u.range._scratchspace &&
>> + (mso.u.range._scratchspace < mso.u.range.start ||
>> + mso.u.range._scratchspace > mso.u.range.end) )
>
> Alignment (extra space) for these two lines.
You mean add an extra space or that there is an extra space?
>
>> diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h
>> index 29ec571..e0bc018 100644
>> --- a/xen/include/public/memory.h
>> +++ b/xen/include/public/memory.h
>> @@ -500,7 +501,14 @@ struct xen_mem_sharing_op {
>> uint64_aligned_t client_gfn; /* IN: the client gfn */
>> uint64_aligned_t client_handle; /* IN: handle to the client page */
>> domid_t client_domain; /* IN: the client domain id */
>> - } share;
>> + } share;
>> + struct mem_sharing_op_range { /* OP_RANGE_SHARE */
>
> Alignment of the comment.
>
> ~Andrew
>
>> + uint64_aligned_t start; /* IN: start gfn. */
>> + uint64_aligned_t end; /* IN: end gfn (inclusive) */
>> + uint64_aligned_t _scratchspace; /* Must be set to 0 */
>> + domid_t client_domain; /* IN: the client domain id */
>> + uint16_t _pad[3]; /* Must be set to 0 */
>> + } range;
>> struct mem_sharing_op_debug { /* OP_DEBUG_xxx */
>> union {
>> uint64_aligned_t gfn; /* IN: gfn to debug */
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-07-19 16:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-18 21:14 [PATCH v7] x86/mem-sharing: mem-sharing a range of memory Tamas K Lengyel
2016-07-18 21:47 ` Andrew Cooper
2016-07-19 16:27 ` Tamas K Lengyel [this message]
2016-07-19 16:49 ` Andrew Cooper
2016-07-19 16:54 ` Tamas K Lengyel
2016-07-19 16:55 ` Andrew Cooper
2016-07-19 16:58 ` Tamas K Lengyel
2016-07-19 7:54 ` Julien Grall
2016-07-19 16:29 ` Tamas K Lengyel
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=CAErYnsiPm4VkrC_9VzCNCyB7SN9yYQ6S+hH3o_BjmGcV_6PotA@mail.gmail.com \
--to=tamas.lengyel@zentific.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.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;
as well as URLs for NNTP newsgroup(s).