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 986BAC001B0 for ; Mon, 3 Jul 2023 20:17:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D3D3280038; Mon, 3 Jul 2023 16:17:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 383A9280030; Mon, 3 Jul 2023 16:17:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 225F3280038; Mon, 3 Jul 2023 16:17:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 151BA280030 for ; Mon, 3 Jul 2023 16:17:58 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D8E3F1A0251 for ; Mon, 3 Jul 2023 20:17:57 +0000 (UTC) X-FDA: 80971411794.12.8FF48C5 Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by imf13.hostedemail.com (Postfix) with ESMTP id C6C2E2000D for ; Mon, 3 Jul 2023 20:17:55 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=xSLVADKn; spf=pass (imf13.hostedemail.com: domain of rientjes@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688415475; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=M1oX1CfdxJh2QCcl3/DLFnwZiVfUuA9OMZRWZ3EO/94=; b=0rBgZ9Y9ZZDuLt7gjHsrKigDPV76UMZjXYQ8XP4ASPoDtkFR984U1L17D2PKTJ28plVcZn /RCxnulDOrCp/VKs9gCAD7PHajIChZi8dKm5q/v4XaG8POAp9Dmfk/+fCZZTY2kUO5hm55 x+BkVTAspJ8+t4CHcuYMfcThRiAMu3Q= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=xSLVADKn; spf=pass (imf13.hostedemail.com: domain of rientjes@google.com designates 209.85.214.172 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688415475; a=rsa-sha256; cv=none; b=BO//EQQS82vVy6KNS4dwMHo/adHkudxekMuA7cz94gzzqMG5JhvBrDx588+E/WQdv1tzDi 9CLqxfy60XnoxwGO01+3Cy4zb7i7p4kJRNhNLHgb4M2Uyscob3nkmlooD4xGtp+KuaO+Mr dhYjgqQnAzGHpZsbws9uYy+74EXqmks= Received: by mail-pl1-f172.google.com with SMTP id d9443c01a7336-1b52875b8d9so414685ad.0 for ; Mon, 03 Jul 2023 13:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688415474; x=1691007474; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=M1oX1CfdxJh2QCcl3/DLFnwZiVfUuA9OMZRWZ3EO/94=; b=xSLVADKndPZ0kY+x4ESRJlpoZAVzR4TY3YjkqLF1Hk/DhmnHaBsKsRR5MAsprR8yTg kDJTc0gIXXIXAJ/Ulo+S23CUqdNHby/32ubaUn30tcZOs3uhjyQPWFoEOxnEuC/juxJV zo30mDnfTmv4xELZ3I05WiIGyAUhGo92NTwDNdXqlewgrvNqKWIeGk83RYWLvVlyzUry RB6N4FowyeKXfBeqTnFA1Fzui6ZsSR+KehYXra9P13eVoIg81VdDNYRRgGoW6dlj9uPY B3OjbSylm2ySCim1uOBfw0mBWsOVkWJfwYC4sg1AzlEIIxAjZcOvita9Q0/EKbIJQIt1 X/tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688415474; x=1691007474; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=M1oX1CfdxJh2QCcl3/DLFnwZiVfUuA9OMZRWZ3EO/94=; b=C+fK0uGzou852p+wSfUi65h48XbGZuchJw/gmingqqbwSUQlFsUG62gWEswHA5H8jG MYaFa9SQ2BKk1e62Xk/l9NhpwOGSZKHMoLtFyUxPcYu26GfCx9czplsEiaFiUMRXo7gN bGIj/g/UCvu3q8smD7iAaZ+09s1Q1WjFKTy3hNJU/TRzcHC3CSeQVujh3lmLu9XMHPmt zDwx0QoxQfPtsImPhlPGTBg6X/SavBZstFeJr+wHJtPf4VFUlBjbj1RyZjbMsTmoVgzr VQ7iy5HMMpifO6prvBPqWPi/+X0Y7xnKq2M2L0yA/ZlBfsjV7Lq2HiBj8HfaOdg6h+TJ rNaw== X-Gm-Message-State: ABy/qLbK6YxdYxavt/EGaZRdTQxc/xSQfrzPw6z8m16gchsvQ9+DJy7L WwO9uoIuKF4KF27zzIYIRYmwVA== X-Google-Smtp-Source: APBJJlHQXopX54fvX7CKUl1nWzeJsezc2kAAc7nqyiwzFaW+CH27dFqDPk6GxjU2uLlr/lONGgf7xQ== X-Received: by 2002:a17:903:22cf:b0:1b3:db56:9ca9 with SMTP id y15-20020a17090322cf00b001b3db569ca9mr24700plg.2.1688415474481; Mon, 03 Jul 2023 13:17:54 -0700 (PDT) Received: from [2620:0:1008:15:17fc:1b56:71df:89b7] ([2620:0:1008:15:17fc:1b56:71df:89b7]) by smtp.gmail.com with ESMTPSA id q14-20020a170902dace00b001b893b689a0sm2600392plx.84.2023.07.03.13.17.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Jul 2023 13:17:54 -0700 (PDT) Date: Mon, 3 Jul 2023 13:17:53 -0700 (PDT) From: David Rientjes To: Julian Pidancet cc: Christoph Lameter , "Lameter, Christopher" , Pekka Enberg , Joonsoo Kim , Andrew Morton , Vlastimil Babka , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Matthew Wilcox , Kees Cook , Rafael Aquini Subject: Re: [PATCH v2] mm/slub: disable slab merging in the default configuration In-Reply-To: Message-ID: <8813897d-4a52-37a0-fe44-a9157716be9b@google.com> References: <20230629221910.359711-1-julian.pidancet@oracle.com> <38083ed2-333b-e245-44e4-2f355e4f9249@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: C6C2E2000D X-Rspam-User: X-Stat-Signature: mwo4wxm8n39uz74zsieocimrzccws6yd X-Rspamd-Server: rspam01 X-HE-Tag: 1688415475-811154 X-HE-Meta: U2FsdGVkX1+W9iR/9VaSqiXZSk7oQPjEvbwyvwA5HgsKQe0keuK+jXpvY+60XkrBoPIkF1IKvV8wKChhKUoFCNU/yc6mNBDYpjhOdw0lhXrW7FwsQ1YRhu8DarElPluIj2PRHPjG9+llXUtCkqhqMPSlXMXikGAoHf4VhsRW5w/rCjF1uwkUx0UhhK2oIJdo/Tbwbf/cNdqoDsdvto1KZUc/N/WBTExz7n6WLHB8BmOmhtWkst7M/2+gjBrWF0vj4NvlAUrjjCMb0790W+ri3nws8MBcRHq+geg7aO8Rx6YSgwvkIs5pAZFO12awqGT5rTX+DNor2BZhgx6U8FD7ONXlZMPO39LMj+rFXo3Xd/t5jc+buNsV02d99D2y3AR+FcEzk7rHaYQRp0koWB+PMPqt5W5tkfk7SZPdTaUY27NoBAP5oTjhd0M935uN4obMDzbpQT5ldqExqiuTQpOlvLAkQTTslGfyJ/R/XKuNrmw5sz2s3oywSDQOjTn4LcLmeTWZ0UfWkeq6F4nvIfVsP8ey0tCP0vbNNZIqwPeV4nFU2MLCkweGHBbRQUWuKmsbnOmID23V4OXpAhzy+UZrSy/HqLq1x9033DqK5t8FeKXl9u+icBd5kq4Zl5I9lGB+RqnjjcPKW4GlTO3KCeMstqSpuRf/vK7uwdOIAHnTJgicwusEk3o+d9EltnPF+OsBrfbalvZkUkgPE/mzCRoiyfmiRhsRqVEORBxs4MR5i59skiiO84915lRhLFJhgNpS2cyJ3GEw52swEoqs4ZfunNUAHAaAnkxXEYBjj0NpM6HMqt0uQ6Z0t4OT4Y/jFV+7nwoLk5h2lRlzCg+Hiizsyii3XWe1dPUnAMRVEn+gi9n9/FbD2iLSO0jDMv/HzR/hnqlYvy2p4ou0RS7hBsVhCRK1W5FFzZd4YX7afGALwd4+NF6jd/HcZWdIDeQoGCPvwnN40Z2JvLQbSvf6XKc nObbNBCF N/vpOr4tyQs2eZhkD0o5az+Z841YEG3otKSGBXYytvoTAZKS6ajUBRXRzTr1Du6T/IssF3Z6D121j8g3Tr4jLREhLjZBBejkwk2rWRXSZ4yYJcpUndW7+uuyIMY9nbBos7EpgKkiO+ga2genLX+DioEkqfrnST9mYS+c3TomDpWKYE+ngu/dShDyG0DM837XJcxo8btwXJueYy4RaQLOhdfv9MRRj2eP82ULn0sXCoRVrYwnwDm27HxN1k/vUQ+4An44/4aslRtX9XAcFCtf8GLHFqx1jUbPkuKj0+idxNwcwSupE/7kLJ0e5FTGu/yc03C0OSvw5AMRgUfAjT4MropK5GWJVb5CP84IVhw8fLFTMWzfDtIJwxfm34XNod9pz0UQW9vQtYceN8+kizOa9oa95YQZrqBkoX5KIJsPcgfcO9Zs1XPPpZyz9p213xLTaoigB 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: On Mon, 3 Jul 2023, Julian Pidancet wrote: > On Mon Jul 3, 2023 at 02:09, David Rientjes wrote: > > I think we need more data beyond just kernbench. Christoph's point about > > different page sizes is interesting. In the above results, I don't know > > the page orders for the various slab caches that this workload will > > stress. I think the memory overhead data may be different depending on > > how slab_max_order is being used, if at all. > > > > We should be able to run this through a variety of different benchmarks > > and measure peak slab usage at the same time for due diligence. I support > > the change in the default, I would just prefer to know what the > > implications of it is. > > > > Is it possible to collect data for other microbenchmarks and real-world > > workloads? And perhaps also with different page sizes where this will > > impact memory overhead more? I can help running more workloads once we > > have the next set of data. > > > > David, > > I agree about the need to perform those tests on hardware using larger > pages. I will collect data if I have the chance to get my hands on one > of these systems. > Thanks. I think arm64 should suffice for things like 64KB pages that Christoph was referring to. We also may want to play around with slub_min_order on the kernel command line since that will inflate the size of slab pages and we may see some different results because of the increased page size. > Do you have specific tests or workload in mind ? Compiling the kernel > with files sitting on an XFS partition is not exhaustive but it is the > only test I could think of that is both easy to set up and can be > reproduced while keeping external interferences as little as possible. > The ones that Binder, cc'd, used to evaluate SLAB vs SLUB memory overhead: hackbench netperf redis specjbb2015 unixbench will-it-scale And Vlastimil had also suggested a few XFS specific benchmarks. I can try to help run benchmarks that you're not able to run or if you can't get your hands on an arm64 system. Additionally, I wouldn't consider this to be super urgent: slab cache merging has been this way for several years, we have some time to do an assessment of the implications of changing an important aspect of kernel memory allocation that will affect everybody. I agree with the patch if we can make it work, I'd just like to study the effect of it more fully beyond some kernbench runs.