On 3/14/2017 12:12 PM, Till Smejkal wrote:
On Mon, 13 Mar 2017, Andy Lutomirski wrote:
On Mon, Mar 13, 2017 at 7:07 PM, Till Smejkal
<till.smej...@googlemail.com> wrote:
On Mon, 13 Mar 2017, Andy Lutomirski wrote:
This sounds rather complicated. Getting TLB flushing right seems
tricky. Why not just map the same thing into multiple mms?
This is exactly what happens at the end. The memory region that is described by
the
VAS segment will be mapped in the ASes that use the segment.
So why is this kernel feature better than just doing MAP_SHARED
manually in userspace?
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.
True, but why is this bad? The shared mapping will be memory resident
regardless, even if backed by a file (unless swapped out under heavy
memory pressure, but arguably that's a feature anyway). More importantly,
having a file name is a simple and consistent way of identifying such
shared memory segments.
With a little work, you can also arrange to map such files into memory
at a fixed address in all participating processes, thus making internal
pointers work correctly.
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.
I am not fully up to speed on NV/pmem stuff, but isn't that exactly what
the DAX mode is supposed to allow you to do? If so, isn't sharing a
mapped file on a DAX filesystem on top of pmem equivalent to what
you're proposing?
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
