Qijia Xu

> Interesting performance numbers. Thanks for doing this effort @qijiax. > > 1. First, I would concentrate on the poor performance of `gramine-direct`. Already with 2 threads, its max achievable...

> I think this is due to the involvement of frequent file access related system calls that need to cross the trusted boundary and served by the untrusted. Also, as...

> @qijiax What build are you using? Could you try current master with `--buildtype=debugoptimized` and then add `--call-graph dwarf` to `perf record`? Would be useful to have call graphs at...

@boryspoplawski @dimakuv Here's the hotspot on `gramine-direct`, with Gramine built with `--buildtype=debugoptimized` and using `--call-graph dwarf` in perf record.  > I don't know why flame graphs can't...

> Looks good now. Could you look deeper into the "16 threads" report? In particular, could you unwrap the first 2-3 items, so that we can see the stack traces...

With the suggestion from @svenkata9 , I re-benchmark on my environment. Threads | 1 | 2 | 4 | 8 | 16 | 32 | 64 -- | -- |...

Thanks for the patch @boryspoplawski . I am using the command `numactl --cpubind=0 --membind=0 gramine-direct mariadbd --user=root` I have a similar result as Sankar's that the performance would have a...

> Oh, wait, looks like you already have this option set? This cannot be true. Please verify your manifest file again. I don't think you correctly set this option. @dimakuv...

Same issue in running TDengine an open-source time series database.

In the case of the memory is full, alloc will return NULL, the application will core dump without this null checking. And there is no other way to avoid this...