From owner-svn-src-all@FreeBSD.ORG Fri Aug 15 16:37:07 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADB402DF; Fri, 15 Aug 2014 16:37:07 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B55E27B7; Fri, 15 Aug 2014 16:37:07 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [69.198.165.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id F26EAAEAC; Fri, 15 Aug 2014 09:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1408120626; x=1408135026; bh=ifH5JvJzjrp1QVAKgITnKOhG0///M/DyQ+y4z6OWII4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=1tbKE4h/9k1EW6WI8vseNyNky0oefpkjuIF6T+l2Yqn+59zCfJAxq/6UQx206idl7 fEHEGwEe3f5a10nD9Lv5nPhICsMijQhHWfXKGbULCUaiCYn1IEL6JXS78WHI2ojsHO ofirdBia2/RrA7t5qumrfbZl0DA+ag9+y/X967BM= Message-ID: <53EE3730.60006@delphij.net> Date: Fri, 15 Aug 2014 09:37:04 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Alan Cox , d@delphij.net, John-Mark Gurney , Xin LI Subject: Re: svn commit: r269963 - head/sys/kern References: <201408140513.s7E5DPRb069698@svn.freebsd.org> <20140814053518.GO83475@funkthat.com> <53EC560B.5000104@delphij.net> <53ED3C6E.10204@rice.edu> In-Reply-To: <53ED3C6E.10204@rice.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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, 15 Aug 2014 16:37:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 08/14/14 15:47, Alan Cox wrote: > On 08/14/2014 01:24, Xin Li wrote: >> On 8/13/14 10:35 PM, John-Mark Gurney wrote: >>> Xin LI wrote this message on Thu, Aug 14, 2014 at 05:13 +0000: >>>> Author: delphij Date: Thu Aug 14 05:13:24 2014 New Revision: >>>> 269963 URL: http://svnweb.freebsd.org/changeset/base/269963 >>>> >>>> Log: Re-instate UMA cached backend for 4K - 64K allocations. >>>> New consumers like geli(4) uses malloc(9) to allocate >>>> temporary buffers that gets free'ed shortly, causing frequent >>>> TLB shootdown as observed in hwpmc supported flame graph. >> >>> Can we do even larger, like 128k for phys io sized blocks? >> >> Sure (Actually I'm running with 128k and 256k buckets enabled on >> my own storage box; with r269964 we can easily add new buckets >> without actually activating them by default). >> >> However, I'm relented to add them right now because the current >> malloc(9) implementation would use the next bucket size, which is >> 2x of the previous one, when the requested size is only a little >> bit larger than the smaller chunk's size. In real world the >> larger bucket could eat more memory than all smaller but greater >> than page-sized bucket combined (the actual consumption is still >> small, though). >> > > The current code already supports sizes that are not powers of 2. > For example, with > > Index: kern/kern_malloc.c > =================================================================== > > - --- kern/kern_malloc.c (revision 269997) > +++ kern/kern_malloc.c (working copy) @@ -152,8 +152,11 @@ struct > { {2048, "2048", }, {4096, "4096", }, {8192, "8192", }, + > {12228, "12228", }, {16384, "16384", }, + {24576, "24576", > }, {32768, "32768", }, + {49152, "49152", }, {65536, "65536", > }, {0, NULL}, }; Unrelated to the functionality, but this would break 'vmstat -m' which assumes power of two allocations... Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJT7jcwAAoJEJW2GBstM+nsGH8P/3ghcaRXNjy+w0bkkya0ixsX KpYvah9S2v7mfk8GtN+xSQaTRtVRqmcWCrRnDLgcmAtRQr0q73T2H5w7a8fVG3sN c3X3c4dyn5XDzrNGmrIe4hAfDNK1F0WPF5nkMpAHhh/EXV5cPynLP2hlZHT6wWa9 MO0ZVAqVjfe1ZIi71AmU69GLGqgTTykMWUo2BKfRZg1LoMektW5Ugj4KlUsvD+SF +FpU7wCSc19br3i27MTsUWU7RKyTyycSOrl/FpZtWMMtyB4RELxUa3QYQQsk2FuM YNWRcBtGaMisNqALMghmJT6l2dtmcPGS47AcyyQnR6w+VziWuYe6Lq/D3iz2EgCM QqFGxp/oDauSjBUfgB83CDfdjrp2x277szBIc9OmvgsyhVgAfDoZzdWuyW2azKi5 c7RN10sqwGhFCLYScgtM0Y2TS8wBGc/uJ7nQMdFUjZ7yNsW3xEU0vAHB0QKar5Tt nIXOiigpO3Ql71l0safPIBvkzWNDHviwuBgGnEgrel86T9tGStRmDCE5YtIaamJV R9Wlhaj7e++4+IC5AEUQvSE1yrg5v5GZVVZEsEBcy1MUlDo5+jqzoxU9lp1sDLAN z7S1PkjWmurFykKl8Vvgi5UHXv5e8u6wFEjf1VDoKw/cqvRWLS/9ifS3ou0EwrJl yBW1Vm9lx6QJohCfq+/q =NvIK -----END PGP SIGNATURE-----