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 590AAEB64DD for ; Mon, 26 Jun 2023 15:23:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C75C58D0008; Mon, 26 Jun 2023 11:23:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C25698D0001; Mon, 26 Jun 2023 11:23:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC6D78D0008; Mon, 26 Jun 2023 11:23:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9BF938D0001 for ; Mon, 26 Jun 2023 11:23:50 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5084F120185 for ; Mon, 26 Jun 2023 15:23:50 +0000 (UTC) X-FDA: 80945269020.30.9438AE8 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf25.hostedemail.com (Postfix) with ESMTP id CE6A9A001F for ; Mon, 26 Jun 2023 15:23:47 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QyeuyP6y; spf=pass (imf25.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687793028; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=U7anx0pZ7kjdapXYs0wiVVtdphHPXWclsse/dRGXpy4=; b=YeE60N0yqeQR5/YxOlhbc4rSthGAMG3BRZqDk7Ej+sONxmCPNXaGkTWoQBGMcaVjP17eag oyQE43YPZKV8Q7dQuF8v3nn04cTJzvVAb6q37jekSD4OKxN1EDqzsKgy6xSqND4Y2V8CnL tmJI29q5OeiNvpWH1ynMatVPB7EgWtU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687793028; a=rsa-sha256; cv=none; b=kCo+e6q0OoCO3ykiAw1BkOMsVNQIwSNGyseAVLV8mSmDSI/EZrgC1WG9PJlK5luh2pMQfk WS3vKDWCepZ5mTa/pPFbwVwLkLbymBxMT5NzZOjZxUC2d2yprYYwPfy2cPVJY9DU+Yayp+ QilEUMnBXU/kFn6zr4XiLHTAT4z4glw= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=QyeuyP6y; spf=pass (imf25.hostedemail.com: domain of dave.hansen@intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687793027; x=1719329027; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=h8sLHtBTnVZJQ+VK9Mju0L08CrA3iMKmjHrpKD0aiOc=; b=QyeuyP6yyzwv6sCwychP4j80IzERk90GtZp77geqs18UaDGlK5fFqxW9 gBoUkWH3KFpbLSMVE7wEDNq9Qr1mkxLTbepYsmCmwfihFUmNvMrzFzYlQ /Sh/C3EutHP8go8AZB0WV7ZrNSpp4RO6TKJ1KfBnE/VOM4ncjiwOqgpfF LR8p2iknoEklmThGv0x+Mg74bPoqqpAUBZ/g62T4S/gzd0qrFI+8l92Ju 1dUa/DFynEIJ0qHdFsakGNWOsfAKqT624fnyzDbhReJkBgqd87a91SsMF h9A+WmogYE4Xp2O4zcO/TqzPctadleKOOcInVPLrvQCsp0RZI5zwZh8/x g==; X-IronPort-AV: E=McAfee;i="6600,9927,10753"; a="358796832" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="358796832" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2023 08:23:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10753"; a="781476701" X-IronPort-AV: E=Sophos;i="6.01,159,1684825200"; d="scan'208";a="781476701" Received: from mshindo-mobl5.amr.corp.intel.com (HELO [10.212.198.145]) ([10.212.198.145]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Jun 2023 08:23:19 -0700 Message-ID: <14f91337-ac7d-52f7-bc86-4091bec4d099@intel.com> Date: Mon, 26 Jun 2023 08:23:19 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v2 2/2] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to MM CPUs Content-Language: en-US To: ypodemsk@redhat.com, mtosatti@redhat.com, ppandit@redhat.com, david@redhat.com, linux@armlinux.org.uk, mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, borntraeger@linux.ibm.com, svens@linux.ibm.com, davem@davemloft.net, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, keescook@chromium.org, paulmck@kernel.org, frederic@kernel.org, will@kernel.org, peterz@infradead.org, ardb@kernel.org, samitolvanen@google.com, juerg.haefliger@canonical.com, arnd@arndb.de, rmk+kernel@armlinux.org.uk, geert+renesas@glider.be, linus.walleij@linaro.org, akpm@linux-foundation.org, sebastian.reichel@collabora.com, rppt@kernel.org, aneesh.kumar@linux.ibm.com, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230620144618.125703-1-ypodemsk@redhat.com> <20230620144618.125703-3-ypodemsk@redhat.com> <680fadba-9104-3914-5175-e207fd3d9246@intel.com> <79f29f99fa07c46dbaee7b802cdd7b477b2d8dd1.camel@redhat.com> From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CE6A9A001F X-Rspam-User: X-Stat-Signature: rzozhbajcdpzjwyoqxtdd87ks8w3j6hw X-Rspamd-Server: rspam03 X-HE-Tag: 1687793027-777226 X-HE-Meta: U2FsdGVkX18RSSnExlmzBKHHlJilaN/4wPB9nS/dTjzpxXaQYPkUNbJ0TKXAmnOQtnrhNB7+ayqEKV843rp2NV7+MKPKn0Zf6+S4dIw4NfyD4e8i5YizkEQ5xinQHw06NLHyAwskCAz0OYqFDnm7cZQL5Cx8Ipedv2epZivTPzqK2PcYeTnIQeQ5xmt94CJgoVELbQ3rhmbVBSzoO5Cc5lJMS/TAz+hPkBZKHFpIPC5btMMa1+wgN/uva6BytUeAA5XhYMLXCcI2KUjnQWbRUFOV3JQKYKrGBWumdOOfDS7PpCD4qYDBYcge8DWBd9xuc/mrwrRkMRPolNN4sg6hFTWc3jgzxFp8hlaOVxGVDeAi6eKCdglYySlCPiECRuNlRDn26871OIxuNlXVl7xj38TqSA5VcGrfIpmXtlAuCMKIE5oYSeNRP9Gfh6hdblXCFNA6tCMEaU3IQtGS3AqbqRQ/37DBo2EY/d7p4MdMHOttIug6RsGkxpGnmQs4L2aWQfZmr3xKmD3J66Dy+M2MsgHGkQfsAtQXUPxPrnhEEPqFNsa/DUuxZ1jOYZHgkMXjdMBojTT8Zg8eXTrlonxY/kxrtDOUPVuMuJstwTmDmi/t6+4fVgQQN8Asq+p6FPb9qCCJD/aYiRlEEOEoupAJ0YntK6dlyEoT1Xuu0RLrbu8fBOVXAPt5Ry8YnemNiLazC8gjrpwn44oy2TwnVU9V7gyaJtwG0n668Ze8USxzh+5Njw/TbZIiHUXYnLtEEslYLUsCNRues0ltC2IrB8HNzbDISlG1ja5EywJvgptBQ3jxE31PBAVhPFppWcCuWyNRtQzRFmIQPiDoSl+eiXVOLvhCKmmm7RpEg3LDxpWxbaEixVAPNuwUNAGJIaHroF7e8E7Jmp4P0sVIzt9beGFh5KDuCdH3EJC5srC580QEndxRPD/COdcu8yC1mRpkZtS+TmYqwpy+8G++mTQFieL hXNLQiXE VX9FPidPSmQByNMqSezLeIPTv1e8Z129tyUpfY//V1AOGk/oPzPKsH/pIGo5vryXu2pSrIBxg+wTNETRLnsQKleBo2TkhGejhfyUWwnO6gS+VkrKjY+NXfCTGE3ZancHdiOgmjEzZIdhIEEuorDDfJNuv+MaqmA+6YOqXUCAFzF/Pzp5XzsMzQpfvZh9Fs1qMlqDH9myeYDflLvXPNtpvV8VQS6s49xGXryCRcjm3DDzzofoAoODGmV2FzmNJLv1LAAS49Psq0ANVi6K+eDgOk/0dxKWaCtc7cgBJLvkSffS0T5K9N+kdLCOffw== 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 6/26/23 07:36, ypodemsk@redhat.com wrote: > On Thu, 2023-06-22 at 06:37 -0700, Dave Hansen wrote: >> On 6/22/23 06:14, ypodemsk@redhat.com wrote: >>> I will send a new version with the local variable as you suggested >>> soon. >>> As for the config name, what about CONFIG_ARCH_HAS_MM_CPUMASK? >> >> The confusing part about that name is that mm_cpumask() and >> mm->cpu_bitmap[] are defined unconditionally. So, they're *around* >> unconditionally but just aren't updated. >> > I think your right about the config name, > How about the > CONFIG_ARCH_USE_MM_CPUMASK? > This has the right semantic as these archs use the cpumask field of the > mm struct. "USE" is still a command. It should, at worst, be "USES". But that's still kinda generic. How about: CONFIG_ARCH_UPDATES_MM_CPUMASK ? >> BTW, it would also be nice to have _some_ kind of data behind this >> patch. >> >> Fewer IPIs are better I guess, but it would still be nice if you >> could say: >> >> Before this patch, /proc/interrupts showed 123 IPIs/hour for an >> isolated CPU. After the approach here, it was 0. >> >> ... or something. > > This is part of an ongoing effort to remove IPIs and this one was found > via code inspection. OK, so it should be something more like: This was found via code inspection, but fixing it isn't very important so we didn't bother to test it any more than just making sure the thing still boots when it is applied. Does that cover it?