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 A93CAC54791 for ; Sun, 10 Mar 2024 19:07:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 212316B0075; Sun, 10 Mar 2024 15:07:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C1006B0078; Sun, 10 Mar 2024 15:07:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B0A46B007B; Sun, 10 Mar 2024 15:07:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EF1096B0075 for ; Sun, 10 Mar 2024 15:07:37 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9D1881A027D for ; Sun, 10 Mar 2024 19:07:37 +0000 (UTC) X-FDA: 81882063354.09.38430AC Received: from eu-smtp-delivery-151.mimecast.com (eu-smtp-delivery-151.mimecast.com [185.58.85.151]) by imf22.hostedemail.com (Postfix) with ESMTP id 72FB6C0012 for ; Sun, 10 Mar 2024 19:07:35 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf22.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710097655; a=rsa-sha256; cv=none; b=M31iNjRcAIg1EjrR2vqOKSjvXJEgt7L7QRwtIeYma6pCDku5BYhG9qGFDaHNd9CmV+O64D dxLH0ymRpTWsnzdwERrDxrMoEml2k8U8MNf7E/A0PAamy6i8s45c3pss8TW1IaA6g59qNT WQTuMjyRnU2BvSE3ubmx1W8Iv3j62g8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=aculab.com; spf=pass (imf22.hostedemail.com: domain of david.laight@aculab.com designates 185.58.85.151 as permitted sender) smtp.mailfrom=david.laight@aculab.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710097655; 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=3jrSb6g7ApMN2D33abZAkqF4Qalf7tF8X8EnjEM7cFg=; b=CUTILlg+hmrVV4JgMKWID1PdpipcmLS/1JPCmph2NUUPHOTygNE+u4ntrkJEzPEUDXxkS7 X8jyMIXU8C3mzxdzEWw9HLcLmTHYnpV3VhyMGTfUCyPpY8PlTdXGZBYXo7Q0R0bFNAIIwU 5pN8HfYKFugYe/tNzja7NMQhVzmXxq0= 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-40-SMhtXwpFNL6OmNRJqlhX_g-1; Sun, 10 Mar 2024 19:07:31 +0000 X-MC-Unique: SMhtXwpFNL6OmNRJqlhX_g-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; Sun, 10 Mar 2024 19:07:41 +0000 Received: from AcuMS.Aculab.com ([::1]) by AcuMS.aculab.com ([::1]) with mapi id 15.00.1497.048; Sun, 10 Mar 2024 19:07:41 +0000 From: David Laight To: 'Matthew Wilcox' , "linux-mm@kvack.org" CC: "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: AQHacMlzWJ9ZLWk00E2JGYCnzpWSgrExV8hA Date: Sun, 10 Mar 2024 19:07:41 +0000 Message-ID: <905fcd730d6e40b992c15ce0fe526941@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-Server: rspam08 X-Rspamd-Queue-Id: 72FB6C0012 X-Stat-Signature: dydmo1xf59ostfgt6z41q3918wayttfz X-Rspam-User: X-HE-Tag: 1710097655-382412 X-HE-Meta: U2FsdGVkX1/ZwqQc3eSx2xx6wgwM4sE3V7p6fysCOnS/EoMU+K+M0PTm/A3mf3YuldSNa1CLkXiaLHfSrTSwC/vTuwc2tG9/9rSjax1JRUmOJlZJOcG7rr6+t28FCV5XEuBp1+adltVFEnOt0jP/9DaQPbmpx49o554HdVMjIACGBoMm99K8NFTSOHQ+FAvpX/g4uwxnKAV7yQkqQNqiExXuPJ45fZ+hrLnIIbcE4QvkWL80s+/stprVTG0o1Mjn+sXks0w5nYzx13eG+00kJXCl16u8fbvEx78Lwb2AhMNKwo/BwEfjwoWjkO1FvNt8QQ+KT6wblLAYxqJbi5MVviBqBtfmM1SfGHxlcAxmw1EVouAeh+NOBGPLH5Mvp2QaqiRzYhjv554bBRoOQjTos+U0T5fFoxD41TMdhRdSx9RzO0f++7QunDtxE2TshHHNMX9cvOui+2MzjETSTJ6dARPm+ZbszxLMSl1cxdzce+0RPKwZYsX/tTxUZwo8f4GRX4CK123aCSSBNwHfIddw8tH2oy7XP3Uw5yvwcgPOpYp3IWk/pv1GXpErkZMv+2cfb3fR9czHrYl35K+Vzi+U+SMs3bhVP4sa5dEOfZ+jdJaUOwZmT2xwqApqfZ2a9i2D6udIjh2PqvKkahsbfb5D7mDZH5BYIFaLy1Cbdl128Nc85NbOn2mTKZE8qaK2hHvyuLlhqVbInOSz5erXKxcQgCdq10ITXi0HicjrGY7gKh2J7zGxjCSA6exlMPOLzlglIEEhp6COT3EiKrihqUDNzsFcEYqsMQoes0GVgxnrkwO1KuX6TJ/jd6YpbwcIrOlG3dTfZna/ZxE9EacVTkMYfRy8HrnPlJX4TvBL1TPej9dRW9V/No1jzKt6Fwa5QAyk X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, 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: 07 March 2024 19:55 >=20 > I've had a few conversations recently about how many objects should be > in a batch in some disparate contextx, so I thought I'd write down my > opinion so I can refer to it in future. TLDR: Start your batch size > around 10, adjust the batch size when measurements tell you to change it. >=20 > In this model, let's look at the cost of allocating N objects from an > allocator. Assume there's a fixed cost, say 4 (units are not relevant > here) for going into the allocator and then there's a 1 unit cost per > object (eg we're taking a spinlock, pulling N objects out of the data > structure and releasing the spinlock again). I think you are trying to measure the length of a piece of string. (and not the ones in the box labelled 'pieces of string too small to keep') What I did recently for a global+local buffer allocator was to make each entry on the global list itself be a list of objects. So if the local list was empty it was a single cmpxchg to grab (about 100) items. Similarly if the local free list got too big a single locked operation would free a block of items. That significantly reduced lock contention. If was necessary to split the free of very long lists - otherwise a single item on the global list could contain silly numbers of items. This was userspace, and we don't talk about the test that ended up with ALL system memory on one linked list. I managed to kill enough (remote) things to get a working shell. It took the system about 20 minutes just to count the linked list! =09David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1= PT, UK Registration No: 1397386 (Wales)