On 02/26/2017 10:01 AM, Sergio Lopez wrote:
> But when the request is being served from memory (a cached read block or
> almost every write, except when using O_DIRECT), you get a cost of ~1us
> on a monolithic kernel vs. ~50us on a microkernel, which is a huge
> difference.
>
> So when I heard about Magenta, I decided to run a quick test, to see if
> Google has found a way to mitigate this issue (spoiler, it has not).
> Testing on a memory-backed filesystem is quite similar to a test on
> cached contents, but without having to deal with real block devices or
> caching algorithms.

Interesting observations and a good benchmark, indeed.

> Thanks, that matches what I got from a quick read of the code. This puts
> HelenOS at a disadvantage against GNU Hurd and Magenta, as it requires
> twice as much IPCs to serve the same I/O operations (both Hurd and
> Magenta get a direct port to the endpoint serving the corresponding
> namespace). Still, it's only 10-20% slower than Magenta [2].

Moreover, the HelenOS file system protocol sends multiple IPC messages
per read/write (IIRC a header message and a read/write data message) and
on reply there is a direct shortcut of the data message to the other
side. So the result will depend both on the architecture of the tested
system (standalone / library VFS, I/O goes / does not go via VFS
everytime) and also on the used IPC protocol.

Btw, it would be interesting to see how these systems compare in an IPC
ping-pong test, such as when you type tester ping_pong in HelenOS.

> I'm sending both the test (read_latency_test.c), which is very simple
> and self-explanatory and the patch I've applied (helenos_realloc.patch).

Thank you.

In the meantime I noticed the issue is reproducible by simply issuing
mkfile -s 64m /tmp/foo in HelenOS (make sure to have enough memory for
this).

I integrated a fix for this in mainline revision 2585. I streamlined
your patch a little bit by adding the detection of a too small area and
an attempt to grow it before the actual allocation code. This allowed me
to get rid of the retry code. Additionally, the area is only grown when
realloc() is sure there are no used blocks that would prevent growing
the block in-place.

Thanks again,
Jakub

_______________________________________________
HelenOS-devel mailing list
[email protected]
http://lists.modry.cz/listinfo/helenos-devel

Reply via email to