Re: [Xen-devel] [PATCH v2 19/20] x86/mem_sharing: reset a fork

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Dec 19, 2019 at 9:58 AM Julien Grall <julien@xxxxxxx> wrote:
>
> Hi,
>
> On 19/12/2019 16:11, Tamas K Lengyel wrote:
> >>> Well, this is only an experimental system that's completely disabled
> >>> by default. Making the assumption that people who make use of it will
> >>> know what they are doing I think is fair.
> >>
> >> I assume that if you submit to upstream this new hypercall then there is
> >> longer plan to have more people to use it and potentially making
> >> "stable". If not, then it raises the question why this is pushed 
> >> upstream...
> >
> > It's being pushed upstream so other people can make use of it, even if
> > it's not "production quality". Beyond what is being sent here there
> > are no longer term plans from Intel (at this point) to support this in
> > any way.
>
> So if this is merged, who is going to maintain it?

It falls under mem_sharing for which I'm listed as "Odd Fixes"
maintainer, which I do in my personal free time. The status there
isn't changing with this new feature.

>
> > The alternative would be that we just release a fork (or just
> > the patches) and walk away.
> >  If the Xen community wants to make the
> > announcement that only code that will have long term support and is
> > "stable" is accepted upstream that's IMHO drastically going to reduce
> > people's interest to share anything.
>
> Sharing is one thing, but if this code is not at least a minimum
> maintained then it is likely the code will not be functional in a year time.

Surprisingly mem_sharing had only minor bitrots in the last ~5 years
in which time it has been pretty much abandoned.

>
> Don't get me wrong, this is a cool feature to have but you make it
> sounds like this is going to be dumped in Xen and never going to be
> touched again. How is this going to be beneficial for the community?

It adds an experimental feature to Xen that people can try out and
well experiment with! It may be useful, it may not be. You yourself
said that this is a cool feature. The fact that there is a JIRA ticket
tracking this also shows there is community interest in having such a
feature available. If down the road that changes and this proves to be
dead code, it can be removed. I don't think that will be necessary
since this isn't even compiled by default anymore though. But anyway,
it makes more sense to get it upstream then carry it out of tree
because it gets more exposure that way, more people may try it out.
Having it in-tree also means that in a couple releases people who are
interested in the feature don't have to go through the process of
rebasing the patchset on newer versions of Xen since it's already
in-tree.

> >>> But if others feel that strongly as well about
> >>> having to have continuation for this I don't really mind adding it.
> >>
> >> I don't think the continuation work is going to be difficult, but if you
> >> want to delay it, then the minimum is to document such assumptions for
> >> your users.
> >
> > I just don't see a use for it because it will never actually execute.
>
> That's a very narrow view of how your hypercall can be used. I know that
> you said that should only be called early, but imagine for a moment the
> user decide to call it much later in the fork process.
>
> > So to me it just looks like unnecessary dead glue.
>
> Try to call the hypercall after enough deduplication happen (maybe
> 20min). Alternatively, give me access to your machine with the code and
> I can show how it can be misused ;).

It will hang for a bit for sure and Linux in dom0 will complain that a
CPU is stuck. But it will eventually finish. It's not like it's doing
all that much. And anyway, if you notice that happening when you call
it it will be an obvious clue that you shouldn't be using it under the
situation you are using it under. Having continuation would hide that.

>
> > But documenting the
> > assumption under which this hypercall should execute is perfectly
> > fair.
>
> You might want to think how the interface would look like with the
> preemption. So the day you decide to introduce preemption you don't have
> to create a new hypercall.

Why would you need to introduce a new hypercall if preemption becomes
necessary? This is not a stable interfaces. It can be removed/changed
completely from one Xen release to the next.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel