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 A7863C43334 for ; Fri, 8 Jul 2022 08:17:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDF8E6B0071; Fri, 8 Jul 2022 04:17:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8FC66B0073; Fri, 8 Jul 2022 04:17:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D575F6B0074; Fri, 8 Jul 2022 04:17:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C65416B0071 for ; Fri, 8 Jul 2022 04:17:25 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 93983350D9 for ; Fri, 8 Jul 2022 08:17:25 +0000 (UTC) X-FDA: 79663228050.27.1250593 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf18.hostedemail.com (Postfix) with ESMTP id 3A6EE1C0058 for ; Fri, 8 Jul 2022 08:17:25 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id r6so14555800edd.7 for ; Fri, 08 Jul 2022 01:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qT5deAffqTtZVxgvmEojgmp/7PC24g9Y8IJXNXkYP7A=; b=ZtYZ4uaxxrkdNypbBx4J9maRKQcdhKkeHfZJBpaBMaGEC5sTp9G2DTYL4wv+jnJAUe SLuqhXjOQ4dsryS2YBSFsxFYP9v+EZumTBTdoRdB9YFTk/YweeZvaFCPyfji2+fdheAC peq/t/nbElA8B1AMy8k47w8A3KBH4GaSA8YaNtpotno2fkakeD4jThqSQ0x7PEMq1utl W260KX4edalLtv/xT7dac16TVmYzdDWKw7Fe4SEXnZ0R4dlF+LieKvtZI0qkV5uYiM9o 0rVxKTIeYrI0Nm2I4JWNhnOOsVesa0PgJ1kxpN/A5kOSgZ73DPsrV0+QiAbJCU9yIpkK 8q9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qT5deAffqTtZVxgvmEojgmp/7PC24g9Y8IJXNXkYP7A=; b=n/aHJWB4/SNzl+hxIkC9H1pTyF2VjJhDOYjZ/dvJqNy1QuDCmlxzVJC1wR2/AqcLrg 8qOgo776Y3CDw+Gm5f7H6BBNETAH2kcY3wSgGozh0RDRqZF1PyPLhUdIkqxtIChT8eZ5 a/+jpLJmasdp3O4RjnNUy39yaCZxNnZeke7YL5YNmRC4qbm3pmm6nnc38m/Oi1W3ux53 6+pWrNA0qas3AIcIpYaU0swWTLIUNXYpa/1jNuruT7lyAcBa5c9Er94pg6wmhsspaYw6 8uT2iONtp2YBpJ+1G5FMAYal+6Xl2ax8sX+8/ohhKW0K4BwuNqfSZIqS7nKLqAIo0P1m zZ1Q== X-Gm-Message-State: AJIora9PMukvbEWX484YwI+qifoI/lAzNik9ojwbnPVPPdFhmV+zin5M +th0Dl5s4AuPRe0UORdeCgbfixe6Wh799nhJOW4= X-Google-Smtp-Source: AGRyM1vkB8bZoNSx6FI2z+hieyN/8K1faoFYu+2IGNBNHn+eOjLS1BKR/WS6kB64rbf9X/xQaPlguTIEyWulWTirYPI= X-Received: by 2002:a05:6402:42cb:b0:43a:5df2:bb5d with SMTP id i11-20020a05640242cb00b0043a5df2bb5dmr3192234edc.36.1657268243904; Fri, 08 Jul 2022 01:17:23 -0700 (PDT) MIME-Version: 1.0 References: <67943544-6DAA-4C8A-A04D-029D2D36C318@vmware.com> <20220708065957.3859-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 8 Jul 2022 20:17:12 +1200 Message-ID: Subject: Re: [PATCH 2/4] mm: rmap: Allow platforms without mm_cpumask to defer TLB flush To: Nadav Amit Cc: Andrew Morton , Arnd Bergmann , Catalin Marinas , Jonathan Corbet , "darren@os.amperecomputing.com" , "guojian@oppo.com" , "huzhanyuan@oppo.com" , "linux-arm-kernel@lists.infradead.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "lipeifeng@oppo.com" , "mgorman@suse.de" , "realmz6@gmail.com" , "v-songbaohua@oppo.com" , "will@kernel.org" , "x86@kernel.org" , "yangyicong@hisilicon.com" , "zhangshiming@oppo.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657268245; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=qT5deAffqTtZVxgvmEojgmp/7PC24g9Y8IJXNXkYP7A=; b=CT7xRcI3eBCGE5SPYngesdBkrEF2a2qbnHrPk9oOwdVvUwZTbkgFSxbuFAMHgUNYiADEzn 1o6dlH8sKyQ9V5Tqp4X2AFym1VWM9orG2h15L5jZGapjMLuOZtalJKHmBDyK29ZtfpveEK u72lW1bqhH0/iMgcYlz2OQ/DyqXY0R4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657268245; a=rsa-sha256; cv=none; b=NcAMJyInke3dGVYBTL30KRAJEF6S4jaZ4P+Ot5ZIblaYQmMfi0aGZyRhJFRpFMjD/cujqB XS0EdGVizRrbUaEoagDYsl6+qPsGdGuP6cCo6R0SZ13VDzRqZNC9zK3cFSmk4fcF2eoRx/ jhgUyLD+MSd5CzdQ15KJjPCEqdHVxmw= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZtYZ4uax; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Queue-Id: 3A6EE1C0058 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZtYZ4uax; spf=pass (imf18.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam03 X-Stat-Signature: j4j3b484iwspkp9bk5bt1c49bnf7k5wk X-HE-Tag: 1657268245-7068 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, Jul 8, 2022 at 8:08 PM Nadav Amit wrote: > > On Jul 7, 2022, at 11:59 PM, Barry Song <21cnbao@gmail.com> wrote: > > >> The cpumask_empty() is indeed just another memory access, which is mos= t > >> likely ok. But wouldn=E2=80=99t adding something like CONFIG_ARCH_HAS_= MM_CPUMASK > >> make the code simpler and (slightly, certainly slightly) more performa= nt? > > > > Yep. good suggestion, Nadav. So the code will be as below, right? > > Hmmm=E2=80=A6 Although it is likely to work (because only x86 and arm wou= ld use this > batch flushing), I think that for consistency ARCH_HAS_MM_CPUMASK should = be > correct for all architectures. > > Is it really only x86 that has mm_cpumask()? i am quite sure there are some other platforms having mm_cpumask(). for example, arm(not arm64). but i am not exactly sure of the situation of each individual arch. thus, i don't risk changing their source code. but arm64 is the second platform looking for tlbbatch, and ARCH_HAS_MM_CPUMASK only affects tlbbatch. so i would expect those platforms to fill their ARCH_HAS_MM_CPUMASK while they start to bringup their tlbbatch? for this moment, we only need to make certain we don't break x86? does it make sense? Thanks Barry >