From: Olaf Hering <olaf@aepfle.de>
To: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] mem_event: use wait queue when ring is full
Date: Mon, 5 Dec 2011 17:20:16 +0100 [thread overview]
Message-ID: <20111205162016.GA13352@aepfle.de> (raw)
In-Reply-To: <f5cf6ad4704fe70f3130b832e530e8b0.squirrel@webmail.lagarcavilla.org>
On Mon, Dec 05, Andres Lagar-Cavilla wrote:
> > + med->bit = bit;
> I think it's been asked before for this to have a more expressive name.
I have to recheck, AFAIK it was the mem_bit where mem_ is redundant.
> > static int mem_event_disable(struct mem_event_domain *med)
> > {
> > + if (!list_empty(&med->wq.list))
> > + return -EBUSY;
> > +
> What does the caller do with EBUSY? Retry?
Yes, and mail the devs at xen-devel that something isn't right ;-)
At least the pager uses this just in the exit path. I dont know about
access and sharing, wether these tools enable/disable more than once at
guest runtime.
> > @@ -287,7 +394,7 @@ int mem_event_domctl(struct domain *d, x
> > if ( p2m->pod.entry_count )
> > break;
> >
> > - rc = mem_event_enable(d, mec, med);
> > + rc = mem_event_enable(d, mec, _VPF_mem_paging, med);
> > }
> > break;
> >
> > @@ -326,7 +433,7 @@ int mem_event_domctl(struct domain *d, x
> > if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL )
> > break;
> >
> > - rc = mem_event_enable(d, mec, med);
> > + rc = mem_event_enable(d, mec, _VPF_mem_access, med);
> Ok, the idea of bit is that different vcpus will sleep with different
> pause flags, depending on the ring they're sleeping on. But this is only
> used in wake_waiters, which is not used by all rings. In fact, why do we
> need wake_waiters with wait queues?
Before this patch, mem_event_unpause_vcpus() was used to resume waiters
for the ring itself and for room in the ring.
Now there is mem_event_wake_waiters(), which indicates the ring is
active, and there is mem_event_wake_requesters() which indicates the
ring has room to place guest requests.
I agree that only _VPF_mem_access is really needed, and _VPF_mem_paging
could be removed because paging without having a ring first is not
possible.
> > @@ -653,7 +643,7 @@ gfn_found:
> > if(ret == 0) goto private_page_found;
> >
> > old_page = page;
> > - page = mem_sharing_alloc_page(d, gfn);
> > + page = alloc_domheap_page(d, 0);
> > if(!page)
> > {
> > /* We've failed to obtain memory for private page. Need to re-add
> > the
> > @@ -661,6 +651,7 @@ gfn_found:
> > list_add(&gfn_info->list, &hash_entry->gfns);
> > put_gfn(d, gfn);
> > shr_unlock();
> > + mem_sharing_notify_helper(d, gfn);
> This is nice. Do you think PoD could use this, should it ever run into a
> ENOMEM situation? And what about mem_paging_prep? Perhaps, rather than a
> sharing ring (which is bit rotted) we could have an ENOMEM ring with a
> utility launched by xencommons listening. The problem, again, is what if
> ENOMEM is itself caused by dom0 (e.g. writable mapping of a shared page)
I have no idea about mem_sharing. I just move the existing code outside
the lock so that mem_event_put_request() is (hopefully) called without
any locks from mem_sharing_get_nr_saved_mfns().
Since there is appearently no user of a sharing ring, this whole new
mem_sharing_notify_helper() is a big no-op.
> > @@ -1167,9 +1159,11 @@ void p2m_mem_access_resume(struct domain
> > if ( rsp.flags & MEM_EVENT_FLAG_VCPU_PAUSED )
> > vcpu_unpause(d->vcpu[rsp.vcpu_id]);
> >
> > - /* Unpause any domains that were paused because the ring was full or
> > no listener
> > - * was available */
> > - mem_event_unpause_vcpus(d);
> > + /* Wake vcpus waiting for room in the ring */
> > + mem_event_wake_requesters(&d->mem_event->access);
> > +
> > + /* Unpause all vcpus that were paused because no listener was
> > available */
> > + mem_event_wake_waiters(d, &d->mem_event->access);
> Is this not used in p2m_mem_paging_resume? Why the difference? Why are two
> mechanisms needed (wake_requesters, wake_sleepers)?
As said above, wake_sleepers is for those who wait for the ring itself,
and wake_requesters is for room in the ring.
p2m_mem_paging_resume() always has a ring, so it does not need to call
wake_sleepers.
Do you have a suggestion for a better name?
Olaf
next prev parent reply other threads:[~2011-12-05 16:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.3332.1323083995.12970.xen-devel@lists.xensource.com>
2011-12-05 15:45 ` [PATCH] mem_event: use wait queue when ring is full Andres Lagar-Cavilla
2011-12-05 16:20 ` Olaf Hering [this message]
2011-12-05 16:34 ` Andres Lagar-Cavilla
2011-12-07 13:20 ` Olaf Hering
2011-12-07 16:27 ` Andres Lagar-Cavilla
[not found] <mailman.4853.1324294828.12970.xen-devel@lists.xensource.com>
2012-01-11 18:02 ` Andres Lagar-Cavilla
2012-01-12 13:59 ` Olaf Hering
2012-01-12 16:11 ` Andres Lagar-Cavilla
2012-01-12 17:50 ` Adin Scannell
[not found] ` <B28ADCC9-CC5A-479D-8A7C-38FF4DB78A55@gridcentric.ca>
2012-01-12 19:22 ` Andres Lagar-Cavilla
2011-12-19 11:39 Olaf Hering
2011-12-22 11:27 ` Tim Deegan
[not found] <mailman.4227.1323785898.12970.xen-devel@lists.xensource.com>
2011-12-15 14:56 ` Andres Lagar-Cavilla
2011-12-16 16:40 ` Olaf Hering
2011-12-16 17:04 ` Andres Lagar-Cavilla
2011-12-16 17:33 ` Olaf Hering
[not found] <mailman.3873.1323460242.12970.xen-devel@lists.xensource.com>
2011-12-10 5:22 ` Andres Lagar-Cavilla
2011-12-13 13:40 ` Olaf Hering
-- strict thread matches above, loose matches on Subject: below --
2011-12-09 19:23 Olaf Hering
2011-12-15 12:43 ` Tim Deegan
2011-12-15 13:15 ` Olaf Hering
2011-12-05 11:19 Olaf Hering
2011-12-05 11:33 ` Olaf Hering
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=20111205162016.GA13352@aepfle.de \
--to=olaf@aepfle.de \
--cc=andres@lagarcavilla.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).