Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp370176pxj; Thu, 27 May 2021 02:06:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrqhzUwwK6leDY5mhvPb9+nI18OGw+RZ9iDgpPhePhEFguUuRt1GR2udWj1mzFvRbbM20l X-Received: by 2002:a17:906:e210:: with SMTP id gf16mr2778811ejb.472.1622106398556; Thu, 27 May 2021 02:06:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622106398; cv=none; d=google.com; s=arc-20160816; b=kdj7sUfgn3HRVplvenP+WepmObHNTGsi+AxoK+uGcWZdvc6UOYZm5u1eDX5uuxvGz5 FjorJjSZx/kTOx0fyFF0s52BGYdyY7TxCzIbm5XdSDe/NJxbEZT8GdrwR4SFerBGs3wi 0opDImTgDWSjytRn3CSKBLHsa31SMSDeoxdxKW1yHO/Ynp10zeM81d9YsBAD9BYF8Kn7 hyI7f2jJBw8dzMAtC6N5tnRarChz0//AXhL4hWF7ccp5COW0WrmDPXjurSZnUzIdpCNd wwIhsxPIQ2D8Q/zfX8oMmWiaVDXy1whAVnu5aqRHiq3CmUobhljkEayLrlavgEVMvmfo ynOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=rGFjk6eRCvPRwLBh9pamgHJ1F7wMBygiapcLCpY26QY=; b=sreUUp9BQxwFbDPD/Y8VCdAvsi55vMHUCGxpIJCom4vatFNu3Z3zhGZE+/2rW/Bl+S /sgYWYzyaRcAgQKPq9xZBhMiCndUREZhwlmtnftzI69Ye5aw+/zKW5AErXEkjBSyMOHH Ml6+W11QukmUQmjgoX6ZTo+m+Apg1/Z5JH/TFEyN1wVlFIZbFFn/p/nHzKnpUeTQ4/rg qc/2k8bny2Bl31PnaV9zucMswqRyxUKD8sNAnAKsHjzz3w5OAn7jrKeNk4u0zucMuNed XQzuYFte0b9c9oCH3OCVQ5hQYcA22/cZVq9IcBtrf5BSfAS/WRuktDvEoHvhrJwldiTU ESzw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g10si1596307edb.485.2021.05.27.02.06.14; Thu, 27 May 2021 02:06:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235524AbhE0JGA (ORCPT + 99 others); Thu, 27 May 2021 05:06:00 -0400 Received: from outbound-smtp53.blacknight.com ([46.22.136.237]:35465 "EHLO outbound-smtp53.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235544AbhE0JF6 (ORCPT ); Thu, 27 May 2021 05:05:58 -0400 Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp53.blacknight.com (Postfix) with ESMTPS id 948DCFB01F for ; Thu, 27 May 2021 10:04:24 +0100 (IST) Received: (qmail 2356 invoked from network); 27 May 2021 09:04:24 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.23.168]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 27 May 2021 09:04:24 -0000 Date: Thu, 27 May 2021 10:04:22 +0100 From: Mel Gorman To: Christoph Hellwig Cc: Andrew Morton , Arnaldo Carvalho de Melo , Andrii Nakryiko , Michal Suchanek , Alexei Starovoitov , Daniel Borkmann , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , open list , Jiri Olsa , Hritik Vijay , bpf , Linux-Net , Linux-MM Subject: Re: [PATCH] mm/page_alloc: Work around a pahole limitation with zero-sized struct pagesets Message-ID: <20210527090422.GA30378@techsingularity.net> References: <20210526080741.GW30378@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 27, 2021 at 09:04:24AM +0100, Christoph Hellwig wrote: > On Wed, May 26, 2021 at 09:07:41AM +0100, Mel Gorman wrote: > > + !defined(CONFIG_DEBUG_LOCK_ALLOC) && \ > > + !defined(CONFIG_PAHOLE_HAS_ZEROSIZE_PERCPU_SUPPORT) > > + /* > > + * pahole 1.21 and earlier gets confused by zero-sized per-CPU > > + * variables and produces invalid BTF. Ensure that > > + * sizeof(struct pagesets) != 0 for older versions of pahole. > > + */ > > + char __pahole_hack; > > + #warning "pahole too old to support zero-sized struct pagesets" > > +#endif > > Err, hell no. We should not mess up the kernel for broken tools that > are not relevant to the kernel build itself ever. What do you suggest as an alternative? I added Arnaldo to the cc as he tagged the last released version of pahole (1.21) and may be able to tag a 1.22 with Andrii's fix for pahole included. The most obvious alternative fix for this issue is to require pahole 1.22 to set CONFIG_DEBUG_INFO_BTF but obviously a version 1.22 that works needs to exist first and right now it does not. I'd be ok with this but users of DEBUG_INFO_BTF may object given that it'll be impossible to set the option until there is a release. The second alternative fix is to embed the local_lock within struct per_cpu_pages. It was shown this was possible in https://lore.kernel.org/linux-rt-users/20210419141341.26047-1-mgorman@techsingularity.net/T/#md1001d7af52ac0d6d214b95e98fe051f9399de64 but I dropped it because it makes the locking protocol complex e.g. config-specific lock-switchin in free_unref_page_list. The last one is wrapping local_lock behind #defines and only defining the per-cpu structures when local_lock_t is a non-zero size. That is simply too ugly for words, the locking patterns should always be the same. -- Mel Gorman SUSE Labs