[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/mm: Improve ring management for memory events. Do not lose guest events


  • To: "Olaf Hering" <olaf@xxxxxxxxx>
  • From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
  • Date: Fri, 13 Jan 2012 12:05:23 -0800
  • Cc: andres@xxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, tim@xxxxxxx, adin@xxxxxxxxxxxxxx
  • Delivery-date: Fri, 13 Jan 2012 20:06:08 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=WffTJVFpxI3prMy7gUL0vBzD52rUBBCcAZzaA8J4ZdOy UW31+IN7Z5BlYLQdXSwXW0mUTnM5BVuOxhXYB7iqP+A+jZ28MKTpz5Lin5zy+h1C 6jgVNNEdxPQTSkN8vn6R6023ij8JZGba+lKxvRkiOun99R6SPUr++6IVGK4qCD0=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

> On Fri, Jan 13, Andres Lagar-Cavilla wrote:
>
>> > p2m_mem_paging_drop_page() should remain void because the caller has
>> > already done its work, making it not restartable. Also it is only
>> called
>> > when a gfn is in paging state, which I'm sure can not happen without a
>> > ring.
>>
>> Well, the rationale is that returning an error code can only help,
>> should
>> new error conditions arise. Keep in mind that the pager and the ring can
>> disappear at any time, so ENOSYS can still happen.
>
> The ring should rather not disappear at all until ->paged_pages drops to
> zero. Unless the goal is a restartable pager,
> XEN_DOMCTL_MEM_EVENT_OP_PAGING_DISABLE should return -EBUSY when
> ->pages_pages is not zero. Then the checks in drop_page and populate can
> be relaxed.

Well, there are two separate things here. Should drop return an error
code? No harm in that. Then there is your point about the ring not going
away if ->paged_pages is nonzero. Which I like, but is currently not
implemented, afaict. Separate patch I guess.

>
>> I'll refresh and add your signed-off-by to cover the portions of the
>> work
>> that originate from your end, is that ok?
>
> I havent finish the review yet, have to check how it may work with wait
> queues in gfn_to_mfn*.

Another case of "the two separate things" :) We definitely look forward to
wait queue support for gfn_to_mfn*. But that's a separate consumer of the
wait queue feature. Are you worried that this patch might break your
gfn_to_mfn* strategy? We did base it on your work.

Thanks,
Andres
>
> Olaf
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.