From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 86096C5475B for ; Mon, 11 Mar 2024 21:42:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F20A86B0130; Mon, 11 Mar 2024 17:42:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED0D56B0131; Mon, 11 Mar 2024 17:42:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D98B56B0132; Mon, 11 Mar 2024 17:42:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C74E26B0130 for ; Mon, 11 Mar 2024 17:42:48 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 9A3181C0AE3 for ; Mon, 11 Mar 2024 21:42:48 +0000 (UTC) X-FDA: 81886083216.26.3AD4DD5 Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by imf12.hostedemail.com (Postfix) with ESMTP id 42C0F40012 for ; Mon, 11 Mar 2024 21:42:45 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710193366; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7kAOmej0vadSCPm4K64QQGvgOs1qKERDnaoFqCrD1BM=; b=ZHRA30jGQyfS40A8FXvqqcWiciZxEXeYLumTNP57JgjfsjrbMwajCz01Gw4AKfrbsNWhGl JSCvBxpbFRKdxABZkyiSJ4cakowfELfIfdGNbc98O711hBnqYLiIb+cPc+gkSTHcex0iuM d6hdXAWhB/Ep2pRYWf82yjZbAMjuwoc= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; spf=pass (imf12.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com; dmarc=pass (policy=none) header.from=aculab.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710193366; a=rsa-sha256; cv=none; b=MUv5bu70QyhFmS8itQTd82oEEnxJoqN9AQC+pygCRj6M/paeCaldDpafI5qCj+Ui5hNqhq 72XqGFTwQmwoLovV3nHF84RmnFF8JljFeaHMY7q97wPJCSLOPqil7d/nDNhvFzZt0GNyDs RyibTGDqRWT763/6KJtzWCA8V3Fmmg0= Received: from AcuMS.aculab.com (156.67.243.121 [156.67.243.121]) by relay.mimecast.com with ESMTP with both STARTTLS and AUTH (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id uk-mta-182-1CQnVePBPnqOGYOB4eHJow-1; Mon, 11 Mar 2024 21:42:41 +0000 X-MC-Unique: 1CQnVePBPnqOGYOB4eHJow-1 Received: from AcuMS.Aculab.com (10.202.163.6) by AcuMS.aculab.com (10.202.163.6) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Mon, 11 Mar 2024 21:42:46 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Mon, 11 Mar 2024 21:42:46 +0000 From: David Laight To: 'Matthew Wilcox' , Dave Chinner CC: "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: On the optimum size of a batch Thread-Topic: On the optimum size of a batch Thread-Index: AQHac2YDWJ9ZLWk00E2JGYCnzpWSgrEzDvkw Date: Mon, 11 Mar 2024 21:42:46 +0000 Message-ID: <5c54bfe5123f4e6390400599427c23b7@AcuMS.aculab.com> References: In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: aculab.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 42C0F40012 X-Rspam-User: X-Stat-Signature: 347mod1rie7iiaqu97n651hn5wwbxhxs X-Rspamd-Server: rspam01 X-HE-Tag: 1710193365-810643 X-HE-Meta: U2FsdGVkX1+BaAPxmaW3wCAyfBVQGHjV9YzniVGlUiNKFIrbQxNF5bqrT4iBUqVmWD3MmXOV3og+xEUG5DV+hXQYNtfWd4UVJ8B0hGFwH6+uz4hxInxRIJBJpWp9cLHArKJOEWSEHAwZDE83Bb91+I9LrH1zevNQ/+KKiuH116VdRC23UavhUOs5BdlwAfF+vxf7y/cZJC2Um2GqxpQ/Gl46EfOjL7EN0nHop5cI5REqNWIbkTydRE2BNN6Nm5i+IqyHtsuKlqWnU//uP7ovo4q/uvgHsHv9mDIR4qvSQxo78dTLzO/gBqhjz5x4bYXbqMaS7VzfERm6P7iVqsHvOeV+z/r255skk2ai72sdQgBMjgcpIMbFLdb9QaFjASJb3gHuEc+jxoV4T5CgC/c0DnIX/y/nFfe/NYVMpNTANJalNgXxDV5T1e1ksxniIwt/ymFgbivo1Pk6y55RwSKkGPfBPSUYySLlwie85CBSOGy9mIq4hbSO0YDBAUI7iyQ3tZqq8WQWAZGI6igz/odtHugSWUivFj4MBfAGGkL6mxbNtjDuPfDihULVqXkLgnVHRqLG0K47jYlA/4PBpDesDCuW11HYOXCH4jYdmRjqQ3P3EQZI2IdL89HPVTEvqFeaSG0lWxPdEf17GJcN6uJNzCzkdWvJ2pbq+JdqL9Zuc46mRyoZd4GprdTjvJmygQzSSiQpxNVWVsZFNmnGJIQ2BR4MBjaLJtk4TOIqq6x/W6T+7E5958rhOamc5bRSZoM/wPrnCRoXPesLM+27rCoWuey5dZZpfq69Jv93m2oRwemzGKyG8EflCwNWsouWxrh/X9iaWYQeftvNVwgeh/nCXGnrMUBOQgxG70h6ddxq1z3V1zySFN/oO/pUlMAsl3ZWqxKzoBnXmIMt0m7KRjjFIFCtOVGm6F9JZfq8EHE+XGOwcTOW5bL2G0jGu8RcNCgXd0lV/wmOX/UDj3Lp6io 7/GHATU3 rETEKxjjfhlYYtQ7x2/RE3etGIWP0F7pWffMOIky7T3V5ook3A0bRqKk9b66aLDYXr5neYgIetaBvP/CIxwlHgsBRRAThDIO2MDCLRX4ucTTawEDeCsb20mjBswYdi1X2WWnnGKl6IDRqZ9GwnRJHMtHvS4BOdQ3m42dxSVep3twjo1HVprlyqhqzUWY2NSBUgTR7HFFY78mv9nd+fzIDfMCBouFVT1Un2XnRawZYyiNs4ltJBE6w/nGz+BbYOTwulicP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Matthew Wilcox > Sent: 11 March 2024 03:42 ... > But that doesn't necessarily mean that you want a larger batch size. > Because you're not just allocating, you're also freeing and over a > large enough timescale the number of objects allocated and freed is > approximately equal. In the SLUB case, your batch size needs to be > large enough to absorb most of the allcation-vs-free bias jitter; that > is if you know they always alternate AFAFAFAFAF a batch size of 2 would > be fine. If you know you get four allocations followed by four frees, > having a batch size of 5 woud be fine. We'd never go to the parent > allocator if we got a AFAAFFAAAFFFAAAAFFFFAAFFAFAAFAAFFF pattern. That isn't really the allocation pattern you need to worry about. Per cpu free list should be large enough to handle it. The problem (as the first people doing a sparc SMP port found) is that you'll get one bit of code that 'pumps' items from one free list to another. So you have to decide that you have too many local free objects and then give some back to the global free list. Keeping them on the global list as a block of 'n' items can make things far better. Indeed 'arrays of pointers' are likely to be better than a linked list. Caches in front of SLUB (or similar) really shouldn't be needed. Except, perhaps, to indicate which list the items come from and, maybe for some extra allocation stats. There might be rcu oddities - where the memory can't be used for a different structure. But there are probably alternative solutions to that one. The page free code is a different problem. I suspect that needs to process batches of items to avoid repeated (expensive) atomic accesses. But it definitely needs to avoid thrashing the L1 cache. =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)