Date: Fri, 30 Oct 2020 17:55:29 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Mateusz Guzik <mjguzik@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r367165 - head/sys/fs/tmpfs Message-ID: <20201030155529.GF2654@kib.kiev.ua> In-Reply-To: <CAGudoHFzaatrWLx4-q3FA=G8wMFkjvPj5kbdgH=7hPyzP-nfJQ@mail.gmail.com> References: <202010301407.09UE7Phw060731@repo.freebsd.org> <CAGudoHGBMFoeOKwZWq2%2B1xC9924Xi2AEt4a1zYgwa_EA3HzAkA@mail.gmail.com> <20201030143851.GE2654@kib.kiev.ua> <CAGudoHFzaatrWLx4-q3FA=G8wMFkjvPj5kbdgH=7hPyzP-nfJQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 30, 2020 at 04:42:39PM +0100, Mateusz Guzik wrote: > On 10/30/20, Konstantin Belousov <kostikbel@gmail.com> wrote: > > On Fri, Oct 30, 2020 at 03:08:32PM +0100, Mateusz Guzik wrote: > >> On 10/30/20, Mateusz Guzik <mjg@freebsd.org> wrote: > >> > Author: mjg > >> > Date: Fri Oct 30 14:07:25 2020 > >> > New Revision: 367165 > >> > URL: https://svnweb.freebsd.org/changeset/base/367165 > >> > > >> > Log: > >> > tmpfs: change tmpfs dirent zone into a malloc type > >> > > >> > It is 64 bytes. > >> > > >> > >> Right now malloc has only power-of-2 zones but I'm looking into > >> changing that. The allocator itself trivially extends to multiply of > >> 16, but stat collection needs reworking. > > > > Either commit message or follow-up do not explain why stopping using > > zone for dirents is useful. Intuition says exactly reverse, dirents > > on tmpfs are allocation-intensive typically. > > > > Off hand the only reasons to use a dedicated zones that I see are: > - use of any of the routines on object creation/destruction > - non-standard flags like NOFREE > - SMR > - high expected allocated count with sizes poorly fit for malloc - Visibility of allocation rate and memory consumption - Detection of leak on zone destruction (tmpfs unmount) > > Since malloc itself is implemented on top of zones, the difference > before/after the patch is that now it can re-use the pre-existing 64 > byte buckets instead of creating its own copy. > > The above follow up was to address potential comments about the size > changing from 64 -- with better malloc granularity this wont be a big > deal. Also note tmpfs already uses malloc to store names. Is it 64 on all arches, on only on LP64 ? I think the later, and then this additionally hits 32bit arches. > > If anything in my opinion the kernel has unnecessary zones (like the > vnode poll one I patched prior to this). For this one I agree, it is low-profile alloc type.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201030155529.GF2654>