Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp71848rwl; Thu, 23 Mar 2023 12:51:37 -0700 (PDT) X-Google-Smtp-Source: AKy350absrePYFmZam7cUBuWpIhseochTE3MuLr/iz263R6SnDzpVqmXQYjHIz5TNzaS9uZRcSqI X-Received: by 2002:a17:906:580b:b0:931:20fd:3d09 with SMTP id m11-20020a170906580b00b0093120fd3d09mr273461ejq.17.1679601097627; Thu, 23 Mar 2023 12:51:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679601097; cv=none; d=google.com; s=arc-20160816; b=TPlt21WlUAubtBqAq8VhjOjRLWgnqa9WfoSkgcUqFjd+9NZkJoOWtGaUS/eJIRLN+8 FcjvJ4O9dsuGf1RSJe2r+q3oOots80cTvm5U9K4YtBkzgEl94sGn0z3Qg1gqxiKhh3vl tFUAE6KiWnpsGqcO9yrSiO0bBr+69iTXzaen+7vF07egbPV7TWf9bKL1jx9CTys0q4FS gpKItPuxubiSnPDNI9ohbckFlxoTgMGb0U5OIFKg+g6CV1OdaTpLJfCTBkWoEmajg1R1 utYxVdFSv+Xs/vUqxx554mJtWVyVpJk0f4+r4n5H0nekXj6khwdhtWOppp17A9YYftrg bfiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=ypydtE3oLX+IwCXZSmMkIoAHUeP4gcZHNPrwfPH1AHw=; b=V4GcpLn0XyM5YyQflE+r+y9i2D+KuH635BoRqGUIFJQu4Yi0OLINvWjWdODFVNbFJv gPmepHEpJ/pwqdBZ+J88oWvZiCH9tRBHp2c8DVmlnClTGLHvzYnN8gRs+Ij7NHFPA5jc o4HNNFy4EP+h7DSFOBxM9nWu5+bZtZpLHT8FtZCelKoxe2022+Ti58eEdkCf0XfFC851 rgecqLK5QFHV4HOi8azhzhxk9stVazKI4+0JTfK84YXceGGSduembF8fjdsaAM0x+gTV iIqMpHNAWscVsY6VxAbAjqtAVITfbxCV9B4QWmgnrbowzZ0MTA/kbiud3aE7UUufSn+v NMcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=Ra4fYq2g; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gr8-20020a170906e2c800b008e6266cd19csi19980986ejb.935.2023.03.23.12.51.06; Thu, 23 Mar 2023 12:51:37 -0700 (PDT) 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=@infradead.org header.s=bombadil.20210309 header.b=Ra4fYq2g; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231681AbjCWTjx (ORCPT + 99 others); Thu, 23 Mar 2023 15:39:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230059AbjCWTjw (ORCPT ); Thu, 23 Mar 2023 15:39:52 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AEBACC11; Thu, 23 Mar 2023 12:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ypydtE3oLX+IwCXZSmMkIoAHUeP4gcZHNPrwfPH1AHw=; b=Ra4fYq2gIVui3gAYJPzljk6ney ozIA/8+lHf8luaaSnU12u3/ZPdY8cp3PruOv8aWuyrklYjMXuD3z0iTOz/nQ5GvUlVJN1u4yk51tt 3AyuICQ0P7lhZSUFHJoaiRw3B8da21yRXFpDmUAZvN0lc2G+xRc0dbhoTcEL0N3DWsbfBcPTljXma kscTH7nLk5NOic0Cbcoq6KcWnoeECfe8p31GTtmirU60N9zG27mFVinYT28WAASiDdbFEdjvKjZog nvXTMQnhfalezDMAqMsW4KmNpxnIDOdDm403yYWJW2m/JE0V+xWf+BOBcPbXCswnp08eoK4WXlxRz MSkjlr7w==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pfQmj-002qcr-1b; Thu, 23 Mar 2023 19:39:41 +0000 Date: Thu, 23 Mar 2023 12:39:41 -0700 From: Luis Chamberlain To: Vlastimil Babka , Matthew Wilcox Cc: Christoph Hellwig , ye.xingchen@zte.com.cn, keescook@chromium.org, yzaikin@google.com, akpm@linux-foundation.org, linmiaohe@huawei.com, chi.minghao@zte.com.cn, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH V5 1/2] mm: compaction: move compaction sysctl to its own file Message-ID: References: <202303221046286197958@zte.com.cn> <8ff68064-3ec6-4aa2-2389-3568483a1bd4@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ff68064-3ec6-4aa2-2389-3568483a1bd4@suse.cz> Sender: Luis Chamberlain X-Spam-Status: No, score=-2.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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 Thu, Mar 23, 2023 at 05:19:15PM +0100, Vlastimil Babka wrote: > On 3/22/23 09:35, Christoph Hellwig wrote: > > On Wed, Mar 22, 2023 at 10:46:28AM +0800, ye.xingchen@zte.com.cn wrote: > >> From: Minghao Chi > >> > >> This moves all compaction sysctls to its own file. > > > > So there's a whole lot of these 'move sysctrls to their own file' > > patches, but no actual explanation of why that is desirable. Please > > I think Luis started this initiative, maybe he can provide the canonical > reasoning :) The kernel/sysctl.c is flooded now with commit log entries which describe a proper rationale, however some folks forget to also include similar rationale in new patches. I try to remind folks when I can, thanks for reminding them to continue to do that. That needs to be fixed in this patch. The summary is its hard to coordiante merge conflicts with all the syctls in one place, best to just put them where they are used. There is a small hidden penalty increase in size to the kernel with the sysctls moves today though and one for which Matthew Wilcox has recently asked for us to pause these moves until we can save more memory. The extra memory is caused by the extra empty struct ctl_table added to the end of the new array. The way to avoid that penalty is to deprecate all APIs in sysctl registation which deal with complex array structures. I have some some of that addressed on my sysctl-next tree (and merged on linux-next) but much more work is required to deprecate the older APIs. I was ready to pause the kernel/sysctl.c moves until those APIs are deprecated and we start having sysctl APIs which allow us to not have the empty array at the end. But as I thought about this just now, the use cases that move the sysctls where __init is used could benefit already in size. For this patch there seems to be a savings of 4 bytes: $ ./scripts/bloat-o-meter vmlinux.old vmlinux add/remove: 1/0 grow/shrink: 1/2 up/down: 346/-350 (-4) Function old new delta vm_compaction - 320 +320 kcompactd_init 167 193 +26 proc_dointvec_minmax_warn_RT_change 104 10 -94 vm_table 2112 1856 -256 Total: Before=19287558, After=19287554, chg -0.00% So I don't think we need to pause this move or others where are have savings. Minghao, can you fix the commit log, and explain how you are also saving 4 bytes as per the above bloat-o-meter results? > > explain why we'd want to split code that is closely related, and now > > requires marking symbols non-static just to create a new tiny source > > file. > > Hmm? I can see the opposite, at least in the compaction patch here. Related > code and variables are moved closer together, made static, declarations > removed from headers. It looks like an improvement to me. Glad this helps. Luis