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 63E29C54EED for ; Mon, 23 Jan 2023 16:14:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFE336B0073; Mon, 23 Jan 2023 11:14:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EAED96B0075; Mon, 23 Jan 2023 11:14:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D76136B0078; Mon, 23 Jan 2023 11:14:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C67EC6B0073 for ; Mon, 23 Jan 2023 11:14:30 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 82DB7140A4D for ; Mon, 23 Jan 2023 16:14:30 +0000 (UTC) X-FDA: 80386561500.19.97BFA6A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 26FC940009 for ; Mon, 23 Jan 2023 16:14:27 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="DvT/eKhy"; spf=pass (imf07.hostedemail.com: domain of jbrouer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=jbrouer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674490468; 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=Hf49zbFN3KLWLBk8hS5GvALY3WWpLu7tA32Veqwn+JY=; b=vMGombYUYTLSBvN7qMBZDyB9pzduJ1fVC6pEPmMtkaU/82uW5gRPYWLNhU5AH4HJOlO4Jr luPBSfOYgcWvmyW5YePUPUvsgEKdmt95uEDTBjwZMyh+YXrdrDILOPPuVEsaWDv9pjzlD1 BBDx/Ob9jSbn3zhPN3XFU0lfNOZ/XF8= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="DvT/eKhy"; spf=pass (imf07.hostedemail.com: domain of jbrouer@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=jbrouer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674490468; a=rsa-sha256; cv=none; b=tncsqMR7e7PRKCKhCfn58PIIRexU5gMcoNBakqm7jPbgvrOrL00yoVYBAx2VwLYGQHQ5Bz ecdA8b3JIjxuMW14XQAaBN4Zmc7TkSvQ7Z8xQiaimhdO470yHXAiTm+jYFM9kOICR+To8h p6Sv/2zVvt422w6x9rxdcSEVRS59tHk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674490467; h=from:from: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=Hf49zbFN3KLWLBk8hS5GvALY3WWpLu7tA32Veqwn+JY=; b=DvT/eKhyW+FNLTssRimfJe4IsG8Z/FjljDu5j5e5tQpRylObunod9XnuRz3S1jztqaNkNH sKZqDC30p2hmZZB65Nf4qoZ1UrjPtuUdCEU82VewilVKg/jfo2D+eyB1EOm+I6/eotfnEa QMbMW5F7XDHScgIxNcbHAYuydCPEIXQ= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-344-ajNARKXKNJCD6dHYA6NNzg-1; Mon, 23 Jan 2023 11:14:25 -0500 X-MC-Unique: ajNARKXKNJCD6dHYA6NNzg-1 Received: by mail-ed1-f70.google.com with SMTP id f11-20020a056402354b00b0049e18f0076dso8803733edd.15 for ; Mon, 23 Jan 2023 08:14:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:content-language:references :to:subject:cc:user-agent:mime-version:date:message-id:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Hf49zbFN3KLWLBk8hS5GvALY3WWpLu7tA32Veqwn+JY=; b=H4xZJSKaJni6zF6n4h/6zi2KDsD0a5JLS2tD9psh1aa8QUndwZ2m5XaSOSqAEPx8z7 5V1YiCp9wWb3abitIx4MohSn4Fsuj6g99flomO65aLUNiS9MwsgujzHWVS9Ts6wPmjkF q/K7G6hzHXhnj44gpacS5pPrOeEurEIgiDu+GRErfka4DNGDstqfqzYNE4tCxQnCLD1k 5wfhqzLXZKX0pOjYDfRXCHEZ4QAurOf8EHV6pTD8XU3+HHm68+filIaoN4BUlW3QJYdI cn52M7A0ergJ4xCzFN9Ok6n6gpzZNtb3kBnvszEAaQJaQmJ3Kv8ZtuTyAjPjYwG/01Yr RN9A== X-Gm-Message-State: AFqh2kqIovu+6xufQA2IeSHgKkPbrMJHUsmWDELUyU2rzs92qFQczTty K1erobZFjzu6htpTPEodx8/R/CBEdNkuZuruQ0XjW3bKKqrGHmXlptC0j8noPB8fWbYyKCf6svb V4gjjbqFgXeQ= X-Received: by 2002:a17:907:6a98:b0:855:2c8e:ad52 with SMTP id ri24-20020a1709076a9800b008552c8ead52mr17843938ejc.29.1674490463188; Mon, 23 Jan 2023 08:14:23 -0800 (PST) X-Google-Smtp-Source: AMrXdXv+Ny52Z+U9d4jr3eRVh9oPEFixUW8YzkJnmICr1vzlSqFUiOIA8sHYmemxRecEArKSShHS/w== X-Received: by 2002:a17:907:6a98:b0:855:2c8e:ad52 with SMTP id ri24-20020a1709076a9800b008552c8ead52mr17843911ejc.29.1674490462981; Mon, 23 Jan 2023 08:14:22 -0800 (PST) Received: from [192.168.42.222] (nat-cgn9-185-107-15-52.static.kviknet.net. [185.107.15.52]) by smtp.gmail.com with ESMTPSA id sa14-20020a170906edae00b008639ddec882sm16028604ejb.56.2023.01.23.08.14.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Jan 2023 08:14:22 -0800 (PST) From: Jesper Dangaard Brouer X-Google-Original-From: Jesper Dangaard Brouer Message-ID: <93665604-5420-be5d-2104-17850288b955@redhat.com> Date: Mon, 23 Jan 2023 17:14:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Cc: brouer@redhat.com, Christoph Lameter , Andrew Morton , Mel Gorman , Joonsoo Kim , penberg@kernel.org, Jakub Kicinski , "David S. Miller" , edumazet@google.com, pabeni@redhat.com, David Rientjes , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin , Alexander Potapenko , Marco Elver , kasan-dev , Matthew Wilcox Subject: Re: [PATCH RFC] mm+net: allow to set kmem_cache create flag for SLAB_NEVER_MERGE To: Vlastimil Babka , netdev@vger.kernel.org, linux-mm@kvack.org References: <167396280045.539803.7540459812377220500.stgit@firesoul> In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 26FC940009 X-Stat-Signature: xdag1xqku6daiumigi8s38s6od9s1dcr X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1674490467-970590 X-HE-Meta: U2FsdGVkX1/ziNbiDtWNbmZKJihz0nwE9yM44H6df8exn15/osLhTTpxkw3n8v9VUiOHxgOlXVp35IA/lBlDubLCCFwjmNlJgNjX3tMtnjq3nMqfK92zdUiq/c1Cl+fefJPJIjzxA4I7VkORrs66ruLnbNobLrG+UDGNk0A+RuHH2EjOa5SRVI78Ae3iQw0AdIR36fwZqtFPQC5K6WUZIwranGfhobj551yOGKzKFbS5rkGkOiz/af4wV+zoyNxQyYvYVMB2/WXleGhKEmIuc7DAXCtyzVXMoAypQeYtOnkmH2SIWQg/R5bC+wLPqWK8TQEXm3w8Ppnkq4TNFLIAB2BwUjF9Z7UfS9NO5faRBbeTLT3ZgO1xcP3QeXCUBucyFQQ2m0VDDJ/LgimmIE5Qe4tKCkHhhX9Lk+IuAcS9H0sODiUAV4lt0Ivvb7YFCqoVozw2Ds1JE19Yn3CQ0J+zI+u6hlG04VDohYKMbGa5JJ8/Z1fR39R3e58gZjRgyuh6iQhh5h50tmp2/+C2Yns5KmB/Oamo1oHmKYXGu8Ew82Zrmr1i6p4N8FPc6lV2j+tO8J9FthJ6Iqh5CUNWYlaebXyQIULanpjJdrE+1CiX7fVsvYLkekAlZCRcygKIlQy2bLAOAJAaheK4YCSOTYLH/aR9TQQoNxAm+uxF5Q3ORH6WBkT1MogdJeEfMuHndMFlPdd2RwopDl7HUEhNF3E/UzPaRvm2rTU6Z7zTBigk4aRYuJXZMySLeaGsy0dMehDOWNMcwf//9DOsMj9ZiPP8am/FM60m2uLUki2134Ai0mWo5pWBy/fsWBSSLBYRNclc0ByaHSL0nb5mbLq6M+WTTpI4Z+LrvVOi6zTe90NcuNsGZSRwTFrdCQrEMEmftk2p1SUr8IkdWGhn3fFxd4SdB1lup8flB56OXX/Vn0V2XuyaO6MDI7GX6hU3GlpAe8oVxrbslIC9aDJQOgt8FlB ZQi9/iph 45hPFak7HmtIUAbUsEj1R/1xfOSmN09L/ggOu73GODlDOAiZH5HUBU2M0pepz9BD//C72yzWOqXTkm9JQjVNERpuNDcMAqs/HDcNYU08vdjM1rLgX6S257zaax0xz8Um0f9QRejcXwLOgBYymCGjFg3YIqVm/J0Zl8HdOvAgpiCZt1ECDYWWRJvtlKroFQn1hPX10yrCELOvrusCGvKFQKclaWMcQcecVoeRmOwur6lgTiWsv9HPEkLZUVzjQnEk5Rh1EAHu0zzhI7+O0d7LnidWNgChxmh6726ptzKGDLiQdFob9qBymycd0gKHaTit25k0EZOYf6o/2jDEfV9OB1u1YaavTUCGHK/sfxnRCbCyiINjV5ff0ndn6qxDxMi23Rcq3YBTS/n4LdaKpB+iqMGYFZ8gumDam6pStJbkkVrbu5eg/FgwE/l+KoSxjU5sux7JPWQMwUv1QRn5ZIG/ZWHzMBkDMQSXg7FKMI4NPUrsdVA3OkXnSYMHZuDcAFHCCT2kHJKeWRE8GkAGl05RVmGivsw== 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 18/01/2023 08.36, Vlastimil Babka wrote: > On 1/17/23 14:40, Jesper Dangaard Brouer wrote: >> Allow API users of kmem_cache_create to specify that they don't want >> any slab merge or aliasing (with similar sized objects). Use this in >> network stack and kfence_test. >> >> The SKB (sk_buff) kmem_cache slab is critical for network performance. >> Network stack uses kmem_cache_{alloc,free}_bulk APIs to gain >> performance by amortising the alloc/free cost. >> >> For the bulk API to perform efficiently the slub fragmentation need to >> be low. Especially for the SLUB allocator, the efficiency of bulk free >> API depend on objects belonging to the same slab (page). > > Incidentally, would you know if anyone still uses SLAB instead of SLUB > because it would perform better for networking? IIRC in the past discussions > networking was one of the reasons for SLAB to stay. We are looking again > into the possibility of removing it, so it would be good to know if there > are benchmarks where SLUB does worse so it can be looked into. > I don't know of any users using SLAB for network performance reasons. I've only been benchmarking with SLUB for a long time. Anyone else on netdev? Both SLUB and SLAB got the kmem_cache bulk API implemented. This is used today in network stack to squeeze extra performance for networking for our SKB (sk_buff) metadata structure (that point to packet data). Details: Networking cache upto 64 of these SKBs for RX-path NAPI-softirq processing per CPU, which is repopulated with kmem_cache bulking API (bulk alloc 16 and bulk free 32). >> When running different network performance microbenchmarks, I started >> to notice that performance was reduced (slightly) when machines had >> longer uptimes. I believe the cause was 'skbuff_head_cache' got >> aliased/merged into the general slub for 256 bytes sized objects (with >> my kernel config, without CONFIG_HARDENED_USERCOPY). > > So did things improve with SLAB_NEVER_MERGE? Yes, but only the stability of the results. The performance tests were microbenchmarks and as Christoph points out there might be gains from more partial slabs when there are more fragmentation. The "overload" microbench will always do maximum bulking, while more real workloads might be satisfied from the partial slabs. I would need to do a broader range of benchmarks before I can conclude if this is always a win. >> For SKB kmem_cache network stack have reasons for not merging, but it >> varies depending on kernel config (e.g. CONFIG_HARDENED_USERCOPY). >> We want to explicitly set SLAB_NEVER_MERGE for this kmem_cache. >> In most distro kernels configs SKB kmem_cache will already not get merged / aliased. I was just trying to make this consistent. >> Signed-off-by: Jesper Dangaard Brouer >> --- >> include/linux/slab.h | 2 ++ >> mm/kfence/kfence_test.c | 7 +++---- >> mm/slab.h | 5 +++-- >> mm/slab_common.c | 8 ++++---- >> net/core/skbuff.c | 13 ++++++++++++- >> 5 files changed, 24 insertions(+), 11 deletions(-) >> >> diff --git a/include/linux/slab.h b/include/linux/slab.h >> index 45af70315a94..83a89ba7c4be 100644 >> --- a/include/linux/slab.h >> +++ b/include/linux/slab.h >> @@ -138,6 +138,8 @@ >> #define SLAB_SKIP_KFENCE 0 >> #endif >> >> +#define SLAB_NEVER_MERGE ((slab_flags_t __force)0x40000000U) > > I think there should be an explanation what this does and when to consider > it. We should discourage blind use / cargo cult / copy paste from elsewhere > resulting in excessive proliferation of the flag. I agree. > - very specialized internal things like kfence? ok > - prevent a bad user of another cache corrupt my cache due to merging? no, > use slub_debug to find and fix the root cause Agree, and the comment could point to the slub_debug trick. > - performance concerns? only after proper evaluation, not prematurely > Yes, and I would need to do more perf eval myself ;-) I don't have time atm, thus I'll not pursue this RFC patch anytime soon. --Jesper