On Wed, Mar 15, 2017 at 12:44:47PM -0700, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: > > > One advantage of VAS segments is that they can be globally queried by > > > user programs > > > which means that VAS segments can be shared by applications that not > > > necessarily have > > > to be related. If I am not mistaken, MAP_SHARED of pure in memory data > > > will only work > > > if the tasks that share the memory region are related (aka. have a common > > > parent that > > > initialized the shared mapping). Otherwise, the shared mapping have to be > > > backed by a > > > file. > > > > What's wrong with memfd_create()? > > > > > VAS segments on the other side allow sharing of pure in memory data by > > > arbitrary related tasks without the need of a file. This becomes > > > especially > > > interesting if one combines VAS segments with non-volatile memory since > > > one can keep > > > data structures in the NVM and still be able to share them between > > > multiple tasks. > > > > What's wrong with regular mmap? > > I never wanted to say that there is something wrong with regular mmap. We just > figured that with VAS segments you could remove the need to mmap your shared > data but > instead can keep everything purely in memory. > > Unfortunately, I am not at full speed with memfds. Is my understanding > correct that > if the last user of such a file descriptor closes it, the corresponding > memory is > freed? Accordingly, memfd cannot be used to keep data in memory while no > program is > currently using it, can it? To be able to do this you need again some > representation
I have a name for application-allocated kernel resources that persist without a process holding a reference to them or a node in the filesystem: a bug. See: sysvipc. Rich _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc