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 0BA1FC0015E for ; Wed, 26 Jul 2023 08:34:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B1D08D0005; Wed, 26 Jul 2023 04:34:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 963488D0001; Wed, 26 Jul 2023 04:34:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 850FA8D0005; Wed, 26 Jul 2023 04:34:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7889A8D0001 for ; Wed, 26 Jul 2023 04:34:56 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 52AA01C9F00 for ; Wed, 26 Jul 2023 08:34:56 +0000 (UTC) X-FDA: 81053102592.25.A96CCD9 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf23.hostedemail.com (Postfix) with ESMTP id 0D71714001C for ; Wed, 26 Jul 2023 08:34:53 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cucQRRFt; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BLEvISpB; dmarc=none; spf=pass (imf23.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690360494; 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:dkim-signature; bh=DNObAGqTS+qyReybr3pgmWoo5MjVeKr0FgRCIVXTNVg=; b=ugGpNTH9BMNpO65qZ3pKTWGfzmjKH/TesG0IMpIZ53GzcA+D/V6fI4NRYZxFt93X1f4hip DKHGNkTjAfWRyzsHworfEnU7VnpZiRrzcslyRD0CgKzdt5cx95N4JcL5Jx/G527wFFukuK CHnf9N+PCVEmIZEBdwn8YkbYvyO/HKE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=cucQRRFt; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=BLEvISpB; dmarc=none; spf=pass (imf23.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690360494; a=rsa-sha256; cv=none; b=OuhGk4+/NbjEAZ3ITlPblgOH2XE2e29HMkR1KfjBdEngsPnQLpdyR5UQy6jrQmLhjykaQF IdrekAlDqCM4nrtEj9eQZKuZcM0g7aMMrTN8t9QIDXxT5obUVaw6UvlOw1Xr4yU2zoEBj1 8WRT1mZWpnERSjemCHXTE3VgkRDKOAs= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 611BE1F74A; Wed, 26 Jul 2023 08:34:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1690360492; h=from:from:reply-to: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=DNObAGqTS+qyReybr3pgmWoo5MjVeKr0FgRCIVXTNVg=; b=cucQRRFtX/YdI8s3iveG5mtAm17SVAuCZTNki8YYp08DO6U850fCw6mNG0Pzn9lZRhUdgQ xoNUBewQI8ZtbVeVsNou/SAA0o6gyzPoJp3o+ANxm+dC8xPQLr3ZeZXMp+hC8tbajd6003 nHLVoecxudbnBiY2ZFZ7V5zu/IW5Xvk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1690360492; h=from:from:reply-to: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=DNObAGqTS+qyReybr3pgmWoo5MjVeKr0FgRCIVXTNVg=; b=BLEvISpBgYWpb5n3MxBk+24/JnmgE4Uzplh0NUj5fLr65tA+65i7STt4qE6EG3rwit97fm 9PZRn8DMKGZtkfDw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2548F139BD; Wed, 26 Jul 2023 08:34:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id REZgCKzawGRPSQAAMHmgww (envelope-from ); Wed, 26 Jul 2023 08:34:52 +0000 Message-ID: <89363892-2752-5b6e-d084-79f54d7e455b@suse.cz> Date: Wed, 26 Jul 2023 10:34:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH v2] mm/slub: disable slab merging in the default configuration To: David Rientjes , Julian Pidancet Cc: Christoph Lameter , "Lameter, Christopher" , Pekka Enberg , Joonsoo Kim , Andrew Morton , 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 References: <20230629221910.359711-1-julian.pidancet@oracle.com> <38083ed2-333b-e245-44e4-2f355e4f9249@google.com> <8813897d-4a52-37a0-fe44-a9157716be9b@google.com> <17349901-df3a-494e-fa71-2584d92526b5@google.com> <3bcfa538-4474-09b7-1812-b4260b09256a@google.com> <7b6b07b3-d8a1-b24f-1df2-bf6080bc5516@google.com> Content-Language: en-US From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0D71714001C X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: u5qfi64sexq855yqtmmfai9n7bzxepoc X-HE-Tag: 1690360493-602553 X-HE-Meta: U2FsdGVkX196NVFLdoL6HEIJtoEuxO5s/Pg6MwMzwtlsnjr3O+TxyQmNRjLlREEfMbX3OwYVwfxEY3MD2KuryIj1VQndU5bFYZ/qmMOEjEJtUbllisb1ZOpD6+Z1VTiRkQ/jD3hZoJVULA1StBkUZ9VR3NhvRvwIp4ISAj5+AkrgtRKizS9o9VcWDAB6Bc3z3YlZJkdDw9LaFLwuyeCuigvfmcsxtc6JnMWZMRy0eO4tonHidpUs06Fiy94S9d1ictuEgBwiYNjx9cjhWduWozC5xrbESSxaE8aI3sMdiFpzhAx/la+TjHmj3cxwtWdH2SkGIRVOv3k2dNvovXF3xFBA47VUQezJcdxAXfzfx7zlPa1YVKsBC7T3yjCuYzBEwEMgXkVxB9SzuPa2/I1hNgXhxGed5qOxcHJgmkemU4rojkdpuWz6M6W3bqngFEeBM9JO7e+TkGfWxcCMy43GIX3bi3u6OO672ApVi0icnbn8XVCju12Uh/9DBnNB74JubEpidohEkGjvh2uUW69CHv57Lb7PWqrdzjRfXPo/zmbs3RtORIgzoj+2FkDFDU1maFySBfzY2VJ/AV8bHiQdgQyYKvnPLPBCbHel3jJAkfLDPZoMQSc3+/0eV7mSCyoXr2MXXvHaNUaGqekGJEn+rzHrzJmzpvIaC+EUgbf1E3cy4jBE874X6ERdOTC+xPmusEp/6IjQ3YVPg/ntYfgBaD3bm+owiICGz+/f3fdpsi6uNhCpOAEzl4MX3HA51N4Qnf5Tpc1/c6nfpR7u8o3o8o+d/fNMKva4MMdXsS6vsEZp4xq2cOe2JhFylXNAc8VHPHC0kmrkuehR3/PkyoPklBfZIqZovJH+GM3U54aM0gt53Pa2DV9SyG41icgz8h1kiR95OZ96tQJQ0Rjc1ZCMdVPUQxAdKtRyI1WV4Nl8h+UHH+bwEBLNdIN7kuO1vVRkaW5BPGvPj2LsXqmSqYe TRNzA6qS 17rQ5ceYrHbdEAVNzKRaUapXjmPLpSMi9s2SYeCY9SIM0JjD7Qy1RZa/WEePzefo4n/d1BjeH2yBveDPGTXI2VfMg5WijhXOaqRN757ejGlSV/ygASKgXGLNCXxPG8mxzZossV9T+8/2qbYfg84667eCW6iV1PGRDmox/7hkaQjLiX9qMEsG1RwDxUuip43WQv5Z3IZJNJ/LyoXHJtuN69WiLHO2Ci72Z/0Gi0to09LE3KFLYBW3CYG2TVXvINfEZbY3Kh2dSCHanFoea4a3lrLnvZA== 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 7/26/23 01:25, David Rientjes wrote: > On Tue, 18 Jul 2023, Julian Pidancet wrote: > >> Hi David, >> >> Many thanks for running all these tests. The amount of attention you've >> given this change is simply amazing. I wish I could have been able to >> assist you by doing more tests, but I've been lacking the necessary >> resources to do so. >> >> I'm as surprised as you are regarding the skylake regression. 20% is >> quite a large number, but perhaps it's less worrying than it looks given >> that benchmarks are usually very different from real-world workloads? >> > > I'm not an expert on context_switch1_per_thread_ops so I can't infere > which workloads would be most affected by such a regression other than to > point out that -18% is quite substantial. It might turn out that this regression is accidental in that merging happens to result in a better caching that benefits the particular skylake cache hierarchy (but not others), because the workload happens to use two different classes of objects that are compatible for merging, and uses them with identical lifetime. But that would be arguably still a corner case and not something to result in a hard go/no-go for the change, as similar corner cases would likely exist that would benefit from not merging. But it's possible the reason for the regression is something less expectable than the above hypotehsis, so indeed we should investigate first. > I'm still hoping to run some benchmarks with 64KB page sizes as Christoph > suggested, I should be able to do this with arm64. > > It's ceratinly good news that the overall memory footprint doesn't change > much with this change. > >> As Kees Cook was suggesting in his own reply, have you given a thought >> about including this change in -next and see if there are regressions >> showing up in CI performance tests results? >> > > I assume that anything we can run with CI performance tests can also be > run without merging into -next? > > The performance degradation is substantial for a microbenchmark, I'd like > to complete the picture on other benchmarks and do a complete analysis > with 64KB page sizes since I think the concern Christoph mentions could be > quite real. We just don't have the data yet to make an informed > assessment of it. Certainly would welcome any help that others would like > to provide for running benchmarks with this change as well :P > > Once we have a complete picture, we might also want to discuss what we are > hoping to achieve with such a change. I was very supportive of it prior > to the -18% benchmark result. But if most users are simply using whatever > their distro defaults to and other users may already be opting into this > either by the kernel command line or .config, it's hard to determine > exactly the set of users that would be affected by this change. Suddenly > causing a -18% regression overnight for this would be surprising for them. What I'd hope to achieve is that if we find out that the differences of merging/not-merging are negligible (modulo corner cases) for both performance and memory, we'd not only change the default, but even make merging more exceptional. It should still be done under SLUB_TINY, and maybe we can keep the slab_merge boot option, but that's it? Because in case they are comparable, not merging has indeed benefits - /proc/slabinfo accounting is not misleading, so in case a bug is reported, it's not neccessary to reboot with nomerge to get the real picture, then there are the security benefits mentioned etc.