Date: Fri, 22 Sep 2017 15:25:06 +0200 From: Mateusz Guzik <mjguzik@gmail.com> To: Gleb Smirnoff <glebius@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Mateusz Guzik <mjg@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r323393 - in head/sys: sys vm Message-ID: <CAGudoHGipv5==rhvUKHdK16uSZs0p%2BMEo344pLZnzODrifrRPg@mail.gmail.com> In-Reply-To: <20170913223231.GN1055@FreeBSD.org> References: <201709101900.v8AJ0c2N059845@repo.freebsd.org> <20170911111127.B870@besplex.bde.org> <CAGudoHG8yVw46cwmpswnozMf-pSjHtBXHDk8DmJ6v=CwOCvWLg@mail.gmail.com> <20170913223231.GN1055@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 14, 2017 at 12:32 AM, Gleb Smirnoff <glebius@freebsd.org> wrote: > On Mon, Sep 11, 2017 at 09:30:10AM +0200, Mateusz Guzik wrote: > M> First, there is a bunch of counter(9) fields. I don't know the original > M> reasoning. I would expect these counters to be statically defined in a > M> per-cpu struct. > > The reasoning was to remove 'struct vmmeter' from the 'struct pcpu', which > sounds inline with your desire to remote struct vmmeter from the kernel > at all. > > Maintainance wise, it is much easier not to bloat 'struct pcpu' with > various global statistics, but keep them as counter(9)s instead. Indeed, > what's the big difference between TCP statistics and VM statistics, why > treat them differently? > > Performance wise, I haven't seen any regressions when collapsed > multiple entities of struct vmmeter sitting in struct pcpu, into > single one with counter(9)s. > My general point is that low-level primitives are weirdly heavier than they need to be. Notable example is critical_enter/exit which are both function calls. As for counter(9), it adds an avoidable read. You are not going to measure the impact as it is due to the kernel being rather pessimized in general. pmc will probably show slight increase in cache misses, but that's it. That said, if maintenance is easier (I don't see why though) that's fine, I'm definitely not interested in fighting over this one. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHGipv5==rhvUKHdK16uSZs0p%2BMEo344pLZnzODrifrRPg>