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 X-Spam-Level: X-Spam-Status: No, score=-7.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED9AFC4708D for ; Fri, 28 May 2021 09:56:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 931B460C3E for ; Fri, 28 May 2021 09:56:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 931B460C3E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 22B496B006C; Fri, 28 May 2021 05:56:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DB506B006E; Fri, 28 May 2021 05:56:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03A356B0070; Fri, 28 May 2021 05:56:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id C609E6B006C for ; Fri, 28 May 2021 05:56:41 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 65B0C180A4349 for ; Fri, 28 May 2021 09:56:41 +0000 (UTC) X-FDA: 78190185402.29.F9AC03D Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf24.hostedemail.com (Postfix) with ESMTP id 6BEC4A001A93 for ; Fri, 28 May 2021 09:56:32 +0000 (UTC) Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 5C5EF218B3; Fri, 28 May 2021 09:56:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1622195799; h=from:from:reply-to: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=dhdQKKFKjVq0AOYJ94M8zTULaqoglwzD51M65ba4TkU=; b=bcrRKaP1GJLre/Zq5cnkwbRfyp/acLxsQqxEV73LpzpcavYCf/E8uconIrVnhvXWjSrGpA IXKbl4+vgZiyCuNaQC4FSOiZUKQOZCq7DX+pYRuwf2bxUKC5fT4SmZZDssutyySovncCL/ yQ4pPvBsRVbg59hkE7UX+cBN/nBeF00= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1622195799; h=from:from:reply-to: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=dhdQKKFKjVq0AOYJ94M8zTULaqoglwzD51M65ba4TkU=; b=2zyj6nHCR2O/JVjQiRV+RYfa3ndqrFN05rtEekrLqwYZQJ63TvusgWLRpPDQF4leVK7sU7 i8w6V+mes0b0otBw== Received: from director2.suse.de (director2.suse-dmz.suse.de [192.168.254.72]) by imap.suse.de (Postfix) with ESMTPSA id 3542C11A98; Fri, 28 May 2021 09:56:39 +0000 (UTC) Date: Fri, 28 May 2021 11:56:38 +0200 From: Michal =?iso-8859-1?Q?Such=E1nek?= To: David Laight Cc: 'Mel Gorman' , 'Andrii Nakryiko' , Christoph Hellwig , Andrew Morton , Arnaldo Carvalho de Melo , 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: <20210528095637.GO8544@kitsune.suse.cz> References: <20210526080741.GW30378@techsingularity.net> <20210527090422.GA30378@techsingularity.net> <8fe547e9e87f40aebce82021d76a2d08@AcuMS.aculab.com> <20210528090421.GK30378@techsingularity.net> <2755b39d723146168e875f3b4a851a0d@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2755b39d723146168e875f3b4a851a0d@AcuMS.aculab.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 6BEC4A001A93 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=bcrRKaP1; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=2zyj6nHC; dmarc=none; spf=pass (imf24.hostedemail.com: domain of msuchanek@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=msuchanek@suse.de X-Rspamd-Server: rspam03 X-Stat-Signature: c8sepi4wpehw8idcotmkw8siekoemwub X-HE-Tag: 1622195792-73413 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 Fri, May 28, 2021 at 09:49:28AM +0000, David Laight wrote: > From: Mel Gorman > > Sent: 28 May 2021 10:04 > > > > On Fri, May 28, 2021 at 08:09:39AM +0000, David Laight wrote: > > > From: Andrii Nakryiko > > > > Sent: 27 May 2021 15:42 > > > ... > > > > I agree that empty structs are useful, but here we are talking about > > > > per-CPU variables only, which is the first use case so far, as far as > > > > I can see. If we had pahole 1.22 released and widely packaged it could > > > > have been a viable option to force it on everyone. > > > ... > > > > > > Would it be feasible to put the sources for pahole into the > > > kernel repository and build it at the same time as objtool? > > > > We don't store other build dependencies like compilers, binutils etc in > > the kernel repository even though minimum versions are mandated. > > Obviously tools/ exists but for the most part, they are tools that do > > not exist in other repositories and are kernel-specific. I don't know if > > pahole would be accepted and it introduces the possibility that upstream > > pahole and the kernel fork of it would diverge. > > The other side of the coin is that is you want reproducible builds > the smaller the number of variables that need to match the better. > > I can see there might be similar issues with the version of libelf-devel > (needed by objtool). > If I compile anything with gcc 10 (I'm doing build-root builds) > I get object files that the hosts 2.30 binutils complain about. > I can easily see that updating gcc and binutils might leave a > broken objtool unless the required updated libelf-devel package > can be found. > Statically linking the required parts of libelf into objtool > would save any such problems. Static libraries are not always available. Especially for core toolchain libraries the developers often have some ideas about which of the static and dynamic libraris is the 'correct' one that they like to enforce. Thanks Michal