Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7724625rwb; Mon, 12 Dec 2022 19:32:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf78dIYMfpEyMhopRrt3K/UI1WI+M5IsIOidL3Fmg0S78sAWOVpSjReR2cqGvplDQwpe2ihD X-Received: by 2002:a17:906:1d47:b0:7ad:9f03:b330 with SMTP id o7-20020a1709061d4700b007ad9f03b330mr3241998ejh.62.1670902350192; Mon, 12 Dec 2022 19:32:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670902350; cv=none; d=google.com; s=arc-20160816; b=vJr2DGwAOZGThRLCWvAnfIvnyP02TrbXe8tJ6vuHyPVCyQRSzJ/o4JEuM/lGKVaPew ddg4MAWn9d22ucaScI0O7o2P5S+OgZGmMGyoXs3PYnqaAllMtFVEMz0WhaKxLTTQltAZ 6JuTZlA8Mn+yHxirkTZ3u0tZBY0NXHWDPoAzFlyOkHINZE9ao29sSFUycy2ORFMtVvbo 2rGkmPsOcnu8jPsQnEzohN1NV0ZIybOdf/Mm+j15P0n6zUGGu0fW/NllwoYr+B1upuPw qcbtF2Wo+7eOBbeEomG8ECioPauu4bQg/hw0SmU8h43A2JYtzm1umLgQwJVFfPRvQWAO zM6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/ToI7hZ2DBEkG61hu0i1tPmmNJiNnyQodEsagogpyA4=; b=CPloiI9uYOjdUV2I5JvCq56h3XPOKWv1NExR4WBa1QSykBiMc6XNKA2tjh1hNNB4/8 hbk3MBPflycqqV21bKxk2SBBPh73Og/z7DHnTI5IIL1GdxyDMp58xwyDvzC0T2fGcjbQ sLnQi/xAd+ECcKuY1XXQOgnzKP33CECiCwyOZI+NS4vIFRmLPRTkqY9jYWdC0qdajJrq whQOm6zTlr5AXbl07Xs1jWDyua30K8uSMzWAMmfQ0wWlNHFYg10x3Zs9MGo+fmr+nsm+ /uIMofSg6oaRNC/qybBogc69dhnXpj5KPtAx13Jc+FDbF5Zuewiiwmhs4QIsjysaOS2w NjmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L1W0F1Hg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qw38-20020a1709066a2600b007ae26c753edsi8597593ejc.52.2022.12.12.19.32.12; Mon, 12 Dec 2022 19:32:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=L1W0F1Hg; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234447AbiLMDFx (ORCPT + 74 others); Mon, 12 Dec 2022 22:05:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234410AbiLMDFi (ORCPT ); Mon, 12 Dec 2022 22:05:38 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 083FE167F8 for ; Mon, 12 Dec 2022 19:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670900683; 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: in-reply-to:in-reply-to:references:references; bh=/ToI7hZ2DBEkG61hu0i1tPmmNJiNnyQodEsagogpyA4=; b=L1W0F1Hgd5FKgAHta63BtNmD+n8pEEqr+FghJlaIgE4mYfrpojPoBU95WGBBi/AQeTkjdA XQM6IxYxiOnNp6Vjsuqc9AqJsNT8smpW/O0JuJr7M6/ySvEQTBxqD/N0NaY7KsOl+ezq88 CNu7/XslORpOYDznuEspHb6L3KCn9qo= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-54-T9RFYZ6OPNKcz28DZtS-yA-1; Mon, 12 Dec 2022 22:04:39 -0500 X-MC-Unique: T9RFYZ6OPNKcz28DZtS-yA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BE79D1C05AE8; Tue, 13 Dec 2022 03:04:38 +0000 (UTC) Received: from localhost (ovpn-12-126.pek2.redhat.com [10.72.12.126]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6A3FE140E949; Tue, 13 Dec 2022 03:04:37 +0000 (UTC) Date: Tue, 13 Dec 2022 11:04:33 +0800 From: Baoquan He To: Dennis Zhou , Vlastimil Babka Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , Roman Gushchin , Andrew Morton , Linus Torvalds , Matthew Wilcox , patches@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/12] mm, slub: remove percpu slabs with CONFIG_SLUB_TINY Message-ID: References: <20221121171202.22080-1-vbabka@suse.cz> <20221121171202.22080-11-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/12/22 at 05:11am, Dennis Zhou wrote: > Hello, > > On Mon, Dec 12, 2022 at 11:54:28AM +0100, Vlastimil Babka wrote: > > On 11/27/22 12:05, Hyeonggon Yoo wrote: > > > On Mon, Nov 21, 2022 at 06:12:00PM +0100, Vlastimil Babka wrote: > > >> SLUB gets most of its scalability by percpu slabs. However for > > >> CONFIG_SLUB_TINY the goal is minimal memory overhead, not scalability. > > >> Thus, #ifdef out the whole kmem_cache_cpu percpu structure and > > >> associated code. Additionally to the slab page savings, this reduces > > >> percpu allocator usage, and code size. > > > > > > [+Cc Dennis] > > > > +To: Baoquan also. Thanks for adding me. > > > > > Wondering if we can reduce (or zero) early reservation of percpu area > > > when #if !defined(CONFIG_SLUB) || defined(CONFIG_SLUB_TINY)? > > > > Good point. I've sent a PR as it was [1], but (if merged) we can still > > improve that during RC series, if it means more memory saved thanks to less > > percpu usage with CONFIG_SLUB_TINY. > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/tag/?h=slab-for-6.2-rc1 > > The early reservation area not used at boot is then used to serve normal > percpu allocations. Percpu allocates additional chunks based on a free > page float count and is backed page by page, not all at once. I get > slabs is the main motivator of early reservation, but if there are other > users of percpu, then shrinking the early reservation area is a bit > moot. Agree. Before kmem_cache_init() is done, anyone calling alloc_percpu() can only get allocation done from early reservatoin of percpu area. So, unless we can make sure nobody need to call alloc_percpu() before kmem_cache_init() now and future. The only drawback of early reservation is it's not so flexible. We can only dynamically create chunk to increase percpu areas when early reservation is run out, but can't shrink early reservation if system doesn't need that much. So we may need weigh the two ideas: - Not allowing to alloc_percpu() before kmem_cache_init(); - Keep early reservation, and think of a economic value for CONFIG_SLUB_TINY. start_kernel() ->setup_per_cpu_areas(); ...... ->mm_init(); ...... -->kmem_cache_init(); __alloc_percpu() -->pcpu_alloc() --> succeed to allocate from early reservation or -->pcpu_create_chunk() -->pcpu_alloc_chunk() -->pcpu_mem_zalloc()