Hi Sergio, thanks for experimenting with HelenOS. Are you going to make a write up about your discoveries? Anyway, please find my further answers below.
On 02/25/2017 02:15 AM, Sergio Lopez wrote: > I've been running a simple test on various OSes, which creates a 64MB > file on a memory-backed filesystem, writing it in 4K chunks, and then > measures the time for a full read and rewrite (without truncating). My > intention was to get some metrics for the latency of minimal read() and > write() operations. In this case involving the test application, VFS and TMPFS servers, the read/rewrite basically tests multiple IPC and memory copy latency from the app via VFS to TMPFS and then back to the app. > Running this test in HelenOS (this is my first contact, after years > wanting to play with it), I've noticed that the results are pretty > decent (almost the same numbers as Google's Magenta). But laying out the > test file takes _a lot_ of time, in the order of several minutes. I guess the number of components over which these operations proceed will have an impact on the latencies. > Taking a look at tmpfs's code, I tracked down the problem to realloc(). > When growing a buffer in relatively large chunks (4K), it always resorts > to malloc()+memcpy(), making the operation unbearable slow. > > I did a quick change, so if the next block in the area is small or not > free, it tries to grow the area itself. This seems to do the trick, and > the time for laying out the file decreases drastically. I can share the > change, it's just 3-4 LoCs, but probably someone with better knowledge > of malloc.c should do a proper implementation. Can you show us what you have done exactly (perhaps even including the testcase) so that we know what fixes the issue? That way we could merge it and give you a full credit for it or suggest improvements / alternate versions. Thanks, Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
