From owner-svn-src-all@freebsd.org Fri Oct 30 16:19:19 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CF46A456057; Fri, 30 Oct 2020 16:19:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CN6vW1rgGz4CN5; Fri, 30 Oct 2020 16:19:19 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wm1-x342.google.com with SMTP id k18so3455482wmj.5; Fri, 30 Oct 2020 09:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5hmnmgLdvpe1vv5XM+6wQ1AiXWVz3jrEMVxjUKgVSws=; b=pv8FuberU8t8wc+7k8NaTbd3bl2T8QIAZhD4lWSDBMzL1KF23TZU/JBn7f0njfzNcs t95s1ChNuAZ66BoYDMCGAYXRAp9p3ieF6fMIKIT8f477b4li3a9pMA27naFiY0+m/Uu/ 2y8XgSeUjM7dNlqApUekCjECiVnMTakVnYCEJW7QwM7MvgPwAcm53YsyhZ3zCS6CWuv0 O3Q8rAxtozxfPQlG1x2zvLoQBwuT/HeslgincuwYe80x6m4bq4Z4whTXsxAVyTdHJRgn ukO3FgA3RSJ0tW4sE8l9JC+mUMJ3kSfncFoqg7YZ778UpxeHUoH91RqZZDRDlrBBbBlz RP8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5hmnmgLdvpe1vv5XM+6wQ1AiXWVz3jrEMVxjUKgVSws=; b=OlqyxijWw91iIpo3oIsS0WUa6cpVc4jueXJWnD2uOzhTHalrtjRuCK41df3F6WdslL 6nj45f+VWuArqbotgg1cgOFu2bni+QgG/uTQRdnlnapHJSun7LtGU2b5Qs2Yn6R2pMUP GbGgFoDCN7fVrNFQfOPKhVoMpVGmueoIocdbdGaq0XkJbRMQgsQlshaJaqaWTonKHJtG /2AeaObSTA7/thbqfbil/JdP55AURBUCwu1OFr8GnPOVVyZbNRxhIBXcHlc44cjqGAmT MHDhZI7m13eHtpR2yzeeNArqmRneZApGWsJGC/SGz3p9f36cYcDhQbXgaVC0/pJMarYw 0BVQ== X-Gm-Message-State: AOAM533cI2AKUdOzPktqg4S9WwumbIp87PgkqvvjsRTXI1NzPAqH1y5J LpOB3zZLcCrsDt2YrbfLddy2CygOi+67dmADyHQ= X-Google-Smtp-Source: ABdhPJz5dZpS2fkhqqkFW3Z3pKn+23sXGdGjVDkPVZtOXy8GQz3jE4x09uQFk7l1u0UqNYHkgxQJS6spXCsHN2ozG0E= X-Received: by 2002:a7b:c20d:: with SMTP id x13mr3781175wmi.83.1604074757846; Fri, 30 Oct 2020 09:19:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a5d:4c4f:0:0:0:0:0 with HTTP; Fri, 30 Oct 2020 09:19:17 -0700 (PDT) In-Reply-To: <20201030155529.GF2654@kib.kiev.ua> References: <202010301407.09UE7Phw060731@repo.freebsd.org> <20201030143851.GE2654@kib.kiev.ua> <20201030155529.GF2654@kib.kiev.ua> From: Mateusz Guzik Date: Fri, 30 Oct 2020 17:19:17 +0100 Message-ID: Subject: Re: svn commit: r367165 - head/sys/fs/tmpfs To: Konstantin Belousov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4CN6vW1rgGz4CN5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=pv8Fuber; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2a00:1450:4864:20::342 as permitted sender) smtp.mailfrom=mjguzik@gmail.com X-Spamd-Result: default: False [-2.73 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.002]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.28)[0.278]; NEURAL_HAM_LONG(-1.01)[-1.011]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::342:from]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[svn-src-all,svn-src-head]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 16:19:19 -0000 On 10/30/20, Konstantin Belousov wrote: > On Fri, Oct 30, 2020 at 04:42:39PM +0100, Mateusz Guzik wrote: >> On 10/30/20, Konstantin Belousov wrote: >> > On Fri, Oct 30, 2020 at 03:08:32PM +0100, Mateusz Guzik wrote: >> >> On 10/30/20, Mateusz Guzik 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 This is tracked as reported by vmstat -m. > - Detection of leak on zone destruction (tmpfs unmount) Zones stopped being per-mount, so now it would be on tmpfs unload. Even then, this once more is provided thanks to malloc types -- there is per-cpu tracking of all allocations within given type and it is validated to be 0 on type destruction. Iow I don't see a loss in functionality. >> >> 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. > I did not check 32-bit. With more granular malloc it is going to be once more exact fit or close it. Either way, with more granular malloc and more zones moved there the total memory use should go down thanks to avoiding spurious per-cpu buckets. >> >> 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. > -- Mateusz Guzik