[RFC PATCH v9 0/8] [PIDNS] Final

[Ákos Uzonyi]

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:
arm:
113807us 613880us
66353us 274007us
71271us 146847us
my system:
23076us 53473us
s390x:
10762us 42090us

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:

static long
execute_syscalls(void)
{
/* Load our PID in the cache */
syscall(__NR_getpid);
...