Re: Implementation of POSIX shared memory objects

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Antti Kantee <pooka%cs.hut.fi@localhost> wrote:
> > - It could not provide determinism for real-time systems.
> 
> How do your memobjs provide determism?  IIRC they were pageable memory.
> What's the difference between mlocking file system pages and mlocking
> shm_memobj pages?

You can wire entire memory object, see uvm_object.c code. No difference
in mlock() behaviour, except it wires just a mapped range of pages.

However, main point is that this relies on assumptions how file-system
internals (eg. tmpfs) work. I am not sure if it's good, if we want to
guarantee determinism.

> > - It would have significant overhead for embedded systems. High bandwidth
> > and performance is a requirement for POSIX shared memory.
> 
> How is writing to memory slower than writing to memory?

If you require tmpfs, it is an overhead for embedded system. Also, tmpfs
has a higher memory consumption. If tmpfs is not used, then requirements
are not met.

> > - Similar bits of kernel functionality (and therefore some complexity)
> > might be needed if we plan to support POSIX typed memory objects.
> 
> I don't know about others, but for me this kind of speculative premature
> "optimization" is a red alert for not taking that route now.

It's not premature optimisation, rather attempt to meet slightly different
objectives. But agree, complexity argument is a very strong one, and I am
not happy about those changes to aobj myself, for now.

-- 
Mindaugas