On Mon, Jan 20, 2020 at 02:24:05PM +0100, Michal Hocko wrote: > On Mon 20-01-20 15:39:35, Kirill A. Shutemov wrote: > > On Mon, Jan 20, 2020 at 12:27:22PM +0100, Michal Hocko wrote: > > > On Mon 20-01-20 13:24:35, Kirill Tkhai wrote: > [...] > > > > Even two threads on common memory need a synchronization > > > > to manage mappings in a sane way. Managing memory from two processes > > > > is the same in principle, and the only difference is that another level > > > > of synchronization is required. > > > > > > Well, not really. The operation might simply attempt to perform an > > > operation on a specific memory area and get a failure if it doesn't > > > reference the same object anymore. What I think we need is some form of > > > a handle to operate on. In the past we have discussed several > > > directions. I was proposing /proc/self/map_anon/ (analogous to > > > map_files) where you could inspect anonymous memory and get a file > > > handle for it. madvise would then operate on the fd and then there > > > shouldn't be a real problem to revalidate that the object is still > > > valid. But there was no general enthusiasm about that approach. There > > > are likely some land mines on the way. > > > > Converting anon memory to file-backed is bad idea and going to backfire. > > I didn't mean to convert. I meant to expose that information via proc > the same way we do for file backed mappings. That shouldn't really > require to re-design the way how anonymous vma work IMO. But I haven't > tried that so there might be many gotchas there. > > There are obvious things to think about though. Such fd cannot be sent > to other processes (SCM stuff), mmap of the file would have to be > disallowed and many others I am not aware of. I am not even pushing this > direction because I am not convinced about how viable it is myself. But > it would sound like a nice extension of the existing mechanism we have > and a file based madvise sounds attractive to me as well because we > already have that. I am not a fan of fd based approach but I already reserved last argument of the API as extendable field so we could use the field as "fd" when we really need that kinds of fine-grained synchronization model if it's not enough with SGISTOP, freezer and so.
