Hi Alexander,
On Mon May 15, 2017 at 15:17:57 +0200, Alexander Fratzer wrote:
Dear L4-Hackers, I have a very simple problem but I can't find the solution in the L4Re-Doc and examples so far. I wrote a very simple Unix-Like Shell with a Filesystem-Server and a Loader-Server and I implemented some Posix-Call as an abstraction for the communication with the Filesystem-Server (virtual). Now I have a problem of double copies for a read-Operation. I want a complete abstraction from the L4Re mechanisms and the underlying Client-Server architecture for the usage of this interface. The (bad) mechanism is as follow:
Function (client side): ssize_t read(int fd, void *buf, size_t count)
Algorithm:
- Allocate Dataspace with size of count.
- Send Cap of Dataspace to the Filesystem-Server.
- Copy content of Dataspace to buf.
- Cleanups.
Function (server side): long VFSSrv::op_file_read(VFS::Rights, TaskRegistry::TaskId task, TaskRegistry::FileDescriptor fd, size_t size, L4::Ipc::Snd_fpage& flexp, size_t& rsize)
Algorithm:
- Get Dataspace-Cap from Ipc-fpage.
- Reserve area with Region-Manager.
- Attach Dataspace to the area.
- Copy content of the file to the attached area.
- Cleanups.
This was my first working solution without focus on runtime but the creation of a new task from an ELF-File of 1.4 MB size takes 20 seconds on Cortex A8. This suxx so I have to optimize. Therefor I need a way to share the content of my file (virtual, heap allocated memory) without copying to the client but i don't find a way to share exist memory over IPC. I think I'm using the Dataspace-mechanism in a wrong way but maybe a Dataspace isn't the right choice in my case. A simple solution would be a new Filesystem which is based on Dataspaces but I don't want to do this. Have anybody a better idea?
Handing around dataspaces for buffer sizes typically used with read/write etc. is too heavy weight. I'd suggest to establish some reasonable-sized amount of shared memory between the client and the server and use this once established memory to copy data back and forth. There is overhead of establishing mappings in address spaces and removing them again (adding/removing page table entries, TLB handling etc.). For handling a couple of kbytes of data copying will just be faster. When the amount of data is becoming bigger, doing mappings finally becomes an option but starting with the shared memory is a good base mechanism.
Adam