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

Reply via email to