[RFC PATCH v9 0/8] [PIDNS] Final
uzonyi.akos at gmail.com
Wed Aug 19 15:45:48 UTC 2020
On Wed, 19 Aug 2020 at 17:26, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Wed, Aug 19, 2020 at 02:00:24AM +0300, Dmitry V. Levin wrote:
> > On Wed, Aug 19, 2020 at 12:37:14AM +0200, Ákos Uzonyi wrote:
> > > On Tue, 18 Aug 2020 at 01:38, Dmitry V. Levin <ldv at altlinux.org> wrote:
> > > > On Mon, Aug 17, 2020 at 12:18:43AM +0200, Ákos Uzonyi wrote:
> > > > > Also, pidns-cache fails on one arm build. I tried to increase the time
> > > > > available for translation, but it didn't help.
> > > >
> > > > Could you add some diagnostics to the test, e.g. how much time did it take
> > > > in the first and in the second case? This way we could see what's going
> > > > on.
> > >
> > > Here are the results:
> > > (no translation | translation with cache | translation without cache)
> > >
> > > the 3 arm builds:
> > > 17846us 76435us 3676880us
> > > 141378us 496301us 3379754us
> > > 8699us 134754us 2974909us
> > >
> > > on my system:
> > > 948us 9358us 916094us
> > I wonder why the cached translation takes that long on your system:
> > 9358 / 948 ≈ 10
Note that cached translation still requires a few syscalls, as we have
to check if cache is still valid.
> > Would it make sense to increase SYSCALL_COUNT so that cache effect would
> > become more visible compared to the translation without cache?
Using 1000 for SYSCALL_COUNT:
These numbers seem less chaotic now :).
Maybe we could try using 20 as the maximum ratio (it could be less,
but I think it's better to have some false negatives, than false
positives). What do you think?
> Also, if the first syscall takes more time to complete because it's not
> cached yet, would it help if it was excluded from the time measurement?
It's already done:
/* Load our PID in the cache */
More information about the Strace-devel