On Wed, Apr 4, 2018 at 2:28 PM, Khem Raj <raj.k...@gmail.com> wrote: > On 3/27/18 8:48 AM, Ross Burton wrote: >> coreutils is now using renameat2() in mv(1) but as this syscall isn't in most >> glibc headers yet it falls back to directly calling syscall(), which pseudo >> doesn't intercept. This results in permission problems as files mysteriously >> move without pseudo knowing. >> >> This patch intercepts syscall() and returns ENOTSUP if renameat2() is being >> called. Thanks to Andre McCurdy for the proof-of-concept that this patch is >> based on. > > what is the performance impact of adding another stack frame and > function call in the chain here. Do we have data ?
I'm not sure if anyone has done any formal measurements, but the overhead of wrapping libc APIs is certainly noticeable in some cases. For example running "git status" in a devshell under pseudo is noticeably slower than from a regular shell. e.g. Within a devshell for glibc: # time git status real 0m1.552s user 0m0.235s sys 0m0.870s >From a regular shell in the glibc workdir: $ time git status real 0m0.067s user 0m0.034s sys 0m0.033s Of course most the overhead here comes from what pseudo does inside the wrapper, not from the wrapper itself. For tasks which are CPU bound (e.g. compiling) and calling into the libc functions which pseudo wraps less often than "git status" does, the overhead will be much less. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
