From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Andres Lagar-Cavilla <andreslc@gridcentric.ca>, xen-devel@lists.xen.org
Cc: "Keir (Xen.org)" <keir@xen.org>,
Zhigang Wang <zhigang.x.wang@oracle.com>,
Tim Deegan <tim@xen.org>, Jan Beulich <JBeulich@suse.com>,
Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall
Date: Thu, 15 Nov 2012 11:35:57 -0800 (PST) [thread overview]
Message-ID: <05bc8ee3-31e3-451e-ad6c-c6912b31f8e7@default> (raw)
In-Reply-To: <99DE5B0D-391E-4845-B9CE-46319825CCD6@gridcentric.ca>
> From: Andres Lagar-Cavilla [mailto:andreslc@gridcentric.ca]
> Subject: Re: [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall
>
> > Ideally, allocation in the presence of existing claims should
> > behave as if the claiming domains had actually already allocated
> > the unclaimed-amount-of-memory. So I'd argue that enforcing
> > the claim should be sacrosanct here.
>
> Well, are we sure that failing an "anonymous" allocations is not going to trigger a BUG_ON? That's a
> lot of code review. If you get this wrong, now Xen suddenly crashes if allocating domains close to the
> max. It doesn't, today, afaict.
I'm not sure I understand your concern. What I said is
that the behavior is the same whether the memory is
allocated for a domain (the pre-claim way) or claimed
and then allocated later. Claim is neither improving
a low-memory situation or making it worse. If Xen
crashes when a claim has been staked (but not yet
satisfied), it would crash the same if the memory
had already been fully allocated.
> >> Similarly, but perhaps of lower priority, there is no integration
> >> with the low-mem handling.
> >
> > I'd also consider this lower priority as Olaf and Andre
> > have argued that the claim mechanism is not needed for
> > sharing/paging so the two mechanisms may not
> > be used together, at least for the foreseeable future.
> > So I plan to skip this, unless you change your mind and
> > consider it a showstopper for acceptance.
>
> This is a slippery slope. Let's not work out the interactions with existing subsystems before adding
> code to the tree. What could go wrong?
Indeed.
> As a data point for everyone, I've found the low men virq extremely useful as a sync interrupt
> signaling to our toolstack that it needs to get its act together and start rebalancing memory, if it
> hasn't yet. I don't see how that cannot be useful to any other toolstack.
Um... very different toolstack paradigm.
Besides (can't resist), in your toolstack, the toolstack is
omniscient about all hypervisor memory allocations, so why
would it _need_ to be notified? ;-) ;-) ;-) ;-) /me ducks
Dan "who holds out single daisy to Andre, previously withdrawn from George
in http://lists.xen.org/archives/html/xen-devel/2012-11/msg00150.html"
next prev parent reply other threads:[~2012-11-15 19:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.16651.1353004500.1399.xen-devel@lists.xen.org>
2012-11-15 18:51 ` [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall Andres Lagar-Cavilla
2012-11-15 19:35 ` Dan Magenheimer [this message]
[not found] <mailman.16877.1353355647.1399.xen-devel@lists.xen.org>
2012-11-19 20:25 ` Andres Lagar-Cavilla
2012-11-19 21:41 ` Dan Magenheimer
2012-11-26 18:01 ` Dan Magenheimer
2012-11-26 18:05 ` Andres Lagar-Cavilla
2012-11-14 23:55 Dan Magenheimer
2012-11-15 10:25 ` Jan Beulich
2012-11-15 18:00 ` Dan Magenheimer
2012-11-16 10:36 ` Jan Beulich
2012-11-19 20:04 ` Dan Magenheimer
2012-11-15 12:25 ` Ian Campbell
2012-11-15 12:39 ` Jan Beulich
2012-11-15 19:19 ` Dan Magenheimer
2012-11-16 10:41 ` Jan Beulich
2012-11-15 19:15 ` Dan Magenheimer
2012-11-16 10:39 ` Jan Beulich
2012-11-16 10:48 ` Ian Campbell
2012-11-19 20:53 ` Dan Magenheimer
2012-11-20 8:16 ` Jan Beulich
2012-11-20 10:16 ` Ian Campbell
2012-11-20 16:33 ` Dan Magenheimer
2012-11-20 16:47 ` Tim Deegan
2012-11-20 17:52 ` Dan Magenheimer
2012-11-21 8:31 ` Jan Beulich
2012-11-21 15:59 ` Dan Magenheimer
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=05bc8ee3-31e3-451e-ad6c-c6912b31f8e7@default \
--to=dan.magenheimer@oracle.com \
--cc=JBeulich@suse.com \
--cc=andreslc@gridcentric.ca \
--cc=keir@xen.org \
--cc=konrad.wilk@oracle.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
--cc=zhigang.x.wang@oracle.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).