On Wed 15-05-19 09:37:23, Oleksandr Natalenko wrote: [...] > > This is way too generic. Please provide something more specific. Ideally > > with numbers. Why those usecases cannot use an existing interfaces. > > Remember you are trying to add a new user interface which we will have > > to maintain for ever. > > For my current setup with 2 Firefox instances I get 100 to 200 MiB saved > for the second instance depending on the amount of tabs. What does prevent Firefox (an opensource project) to be updated to use the explicit merging? [...] > Answering your question regarding using existing interfaces, since > there's only one, madvise(2), this requires modifying all the > applications one wants to de-duplicate. In case of containers with > arbitrary content or in case of binary-only apps this is pretty hard if > not impossible to do properly. OK, this makes more sense. Please note that there are other people who would like to see certain madvise operations to be done on a remote process - e.g. to allow external memory management (Android would like to control memory aging so something like MADV_DONTNEED without loosing content and more probably) and potentially other madvise operations. Or maybe we need a completely new interface other than madvise. In general, having a more generic API that would cover more usecases is definitely much more preferable than one ad-hoc API that handles a very specific usecase. So please try to think about a more generic -- Michal Hocko SUSE Labs
