[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. Thanks, Tamas _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |