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 1FD09C32771 for ; Thu, 22 Sep 2022 03:15:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 64A14940008; Wed, 21 Sep 2022 23:15:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5F8FA940007; Wed, 21 Sep 2022 23:15:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C0C6940008; Wed, 21 Sep 2022 23:15:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3D06D940007 for ; Wed, 21 Sep 2022 23:15:36 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 15B96AB4E8 for ; Thu, 22 Sep 2022 03:15:36 +0000 (UTC) X-FDA: 79938256272.21.940AEFC Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 5B4A58000E for ; Thu, 22 Sep 2022 03:15:35 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CAACE143D; Wed, 21 Sep 2022 20:15:40 -0700 (PDT) Received: from [10.162.43.8] (unknown [10.162.43.8]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8EAB43F5A1; Wed, 21 Sep 2022 20:15:24 -0700 (PDT) Message-ID: <0236922f-841e-c6d8-c9ee-599d72c458d3@arm.com> Date: Thu, 22 Sep 2022 08:45:22 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v3 4/4] arm64: support batched/deferred tlb shootdown during page reclamation Content-Language: en-US To: Nadav Amit Cc: Yicong Yang , Andrew Morton , Linux MM , "linux-arm-kernel@lists.infradead.org" , "x86@kernel.org" , "catalin.marinas@arm.com" , Will Deacon , "linux-doc@vger.kernel.org" , "corbet@lwn.net" , "peterz@infradead.org" , "arnd@arndb.de" , "linux-kernel@vger.kernel.org" , "darren@os.amperecomputing.com" , "yangyicong@hisilicon.com" , "huzhanyuan@oppo.com" , "lipeifeng@oppo.com" , "zhangshiming@oppo.com" , "guojian@oppo.com" , "realmz6@gmail.com" , "linux-mips@vger.kernel.org" , "openrisc@lists.librecores.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , Barry Song <21cnbao@gmail.com>, "wangkefeng.wang@huawei.com" , "xhao@linux.alibaba.com" , "prime.zeng@hisilicon.com" , Barry Song , Mel Gorman References: <20220822082120.8347-1-yangyicong@huawei.com> <20220822082120.8347-5-yangyicong@huawei.com> <888da5f3-104c-3929-c21e-c710922d6f1e@arm.com> <36B9DE22-E3BC-4CB2-8E3F-B21B61434CD3@vmware.com> From: Anshuman Khandual In-Reply-To: <36B9DE22-E3BC-4CB2-8E3F-B21B61434CD3@vmware.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663816535; 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; bh=Xy5+sfDV69k22LUlpf5wX39Bwjuk9efRTBbSsSdDHkM=; b=S0DGGgSGxS/ibHgnX20uMbXpr0xuHQK54Lo1NeryBMHznOsmwCgzAFWBFKabB41/d70CKf gYF1Iw70qNuXOb42NvooD7/n+t6/B67fWL9CXNoZ/ANrayckS2pBzEsyeSb0aQ5NpK4JHl btHrTpn9lo/3ZOQ45Jmgct0lsV4yAUE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663816535; a=rsa-sha256; cv=none; b=gER6VTD/6HKyvrWQZkVFYhELIVmxl3ovRMG6b5N13/SEMhiX2ZNmk3jZjXiXHt6MnjlmPO 6iz35A/asiUdFpMB9uiAWWqS9ov/1NfdhzSZNn/VUEVzex4HiIwRdYntO0TrZcrYKNPten n89dRdkuFGWXO69odWea3ouYJhEpEGc= X-Stat-Signature: a813e8iknetx8etp7hjy1rjjtrgsiqh9 X-Rspamd-Queue-Id: 5B4A58000E X-Rspam-User: Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com X-Rspamd-Server: rspam03 X-HE-Tag: 1663816535-473542 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 9/21/22 12:47, Nadav Amit wrote: > On Sep 20, 2022, at 11:53 PM, Anshuman Khandual wrote: > >> ⚠ External Email >> >> On 8/22/22 13:51, Yicong Yang wrote: >>> +static inline void arch_tlbbatch_add_mm(struct arch_tlbflush_unmap_batch *batch, >>> + struct mm_struct *mm, >>> + unsigned long uaddr) >>> +{ >>> + __flush_tlb_page_nosync(mm, uaddr); >>> +} >>> + >>> +static inline void arch_tlbbatch_flush(struct arch_tlbflush_unmap_batch *batch) >>> +{ >>> + dsb(ish); >>> +} >> >> Just wondering if arch_tlbbatch_add_mm() could also detect continuous mapping >> TLB invalidation requests on a given mm and try to generate a range based TLB >> invalidation such as flush_tlb_range(). >> >> struct arch_tlbflush_unmap_batch via task->tlb_ubc->arch can track continuous >> ranges while being queued up via arch_tlbbatch_add_mm(), any range formed can >> later be flushed in subsequent arch_tlbbatch_flush() ? >> >> OR >> >> It might not be worth the effort and complexity, in comparison to performance >> improvement, TLB range flush brings in ? > > So here are my 2 cents, based on my experience with Intel-x86. It is likely > different on arm64, but perhaps it can provide you some insight into what > parameters you should measure and consider. > > In general there is a tradeoff between full TLB flushes and entry-specific > ones. Flushing specific entries takes more time than flushing the entire > TLB, but sade TLB refills. Right. > > Dave Hansen made some calculations in the past and came up with 33 as a > magic cutoff number, i.e., if you need to flush more than 33 entries, just > flush the entire TLB. I am not sure that this exact number is very > meaningful, since one might argue that it should’ve taken PTI into account > (which might require twice as many TLB invalidations). Okay. > > Anyhow, back to arch_tlbbatch_add_mm(). It may be possible to track ranges, > but the question is whether you would actually succeed in forming continuous > ranges that are eventually (on x86) smaller than the full TLB flush cutoff > (=33). Questionable (perhaps better with MGLRU?). This proposal here for arm64 does not cause a full TLB flush ever. It creates individual TLB flushes all the time. Hence the choice here is not between full TLB flush and possible range flushes. Choice is actually between individual TLB flushes and range/full TLB flushes. > > Then, you should remember that tracking should be very efficient, since even > few cache misses might have greater cost than what you save by > selective-flushing. Finally, on x86 you would need to invoke the smp/IPI > layer multiple times to send different cores the relevant range they need to > flush. Agreed, these reasons make it much difficult to gain any more performance. > > IOW: It is somewhat complicated to implement efficeintly. On x86, and > probably other IPI-based TLB shootdown systems, does not have clear > performance benefit (IMHO). Agreed, thanks for such a detailed explanation, appreciate it.