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

[Dmitry V. Levin]

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:
> > > > From: Uzonyi Ákos <uzonyi.akos at gmail.com>
> > > >
> > > > I made the requested changes, added more test cases to trie test, and fixed some
> > > > trie bugs.
> > > >
> > > > The travis build [1] unfortunately shows some errors. On ppc mknod test fails,
> > > > but I have no idea why. Mknod is unrelated to my code. Do you have any idea?
> > >
> > > Something is broken in their ppc system: apparently, they allow the mknod
> > > syscall to exit without an error in cases where is must fail with EEXIST
> > > because the target file already exists.  This violates the contract:
> > > "If pathname already exists, or is a symbolic link, this call fails with
> > > an EEXIST error."  I suppose they use some kind of mknod interception,
> > > and it doesn't implement the expected semantics.
> > >
> > > We can either come up with a workaround or report a bug and let them fix it.
> > 
> > What seems really strange is that only the last two mknod does not
> > fail with EEXIST.
> 
> Only the last two mknod calls are trying to create devices,
> all the rest aren't.  This looks like an error in some seccomp filter.
> 
> > > > 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
> 
> Would it make sense to increase SYSCALL_COUNT so that cache effect would
> become more visible compared to the translation without cache?

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?


-- 
ldv