[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Implementation of POSIX shared memory objects
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
> > - 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.
Main Index |
Thread Index |