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

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

> >>> 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.
> This falls under a "minimum maintained". This wasn't clear from your
> previous statement stating there will be no support.

Sure, I meant there is no support from Intel (ie. it's not part of my
job-description nor do I get payed to support this long-term). I
usually check during the RC test days that it's at least functional by
doing some testing manually. But it's pretty ad-hoc when and if I do
that (hence the Odd fixes status).

> >
> >>>>> 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.
> I am not going to argue more as this is an experimental feature. But
> this will be a showstopper if we ever consider mem_sharing to be
> supported (or even security supported).
> Meanwhile please document the assumption.

Ack, already did.


Xen-devel mailing list



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