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 09251C77B75 for ; Tue, 16 May 2023 06:40:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62E62900004; Tue, 16 May 2023 02:40:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DE9B900002; Tue, 16 May 2023 02:40:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A5FE900004; Tue, 16 May 2023 02:40:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 36934900002 for ; Tue, 16 May 2023 02:40:51 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 01FEAAF5EE for ; Tue, 16 May 2023 06:40:50 +0000 (UTC) X-FDA: 80795170302.26.91EF472 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf21.hostedemail.com (Postfix) with ESMTP id 4F9341C0007 for ; Tue, 16 May 2023 06:40:49 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=x0pf8UNw; dkim=pass header.d=linutronix.de header.s=2020e header.b="/kL8pSGl"; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684219249; a=rsa-sha256; cv=none; b=6dqeZTlArp3j99j3eDUg5wAP9+cXsARuU9Vdq87itgP4yBcwFA1ATj3eyfv3a+30CPggSt dpUTRiaDT2lZfyOkT+ECy/nnWb1fyB28p2/312ekxDccluxUlXhmAYEsD6JU82/QGedpkC SMHRE8l9eekVDOS+h2pRn0wDhIRMG8A= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=x0pf8UNw; dkim=pass header.d=linutronix.de header.s=2020e header.b="/kL8pSGl"; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684219249; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Zfmn83rF/TWm/I9paO17+6NNkBLlCT275s9VXWrN7B4=; b=lngGH6edB0xGpOtScYqrtmrr4QV2w7XEnCmnk0ujJr6Gp7SnbDC5O65Hn19XP/7e/VjNMy vpuoFMa2KQ+YZ1k864g2pgW9++QME13BnUy8P+b/BtG38ekNYWU2XB5oR//Bjr7W+DjagW AcN0ZCcTtttD9Ffo/M4zTH1BcwIOt/w= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684219247; h=from:from:reply-to:subject:subject: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=Zfmn83rF/TWm/I9paO17+6NNkBLlCT275s9VXWrN7B4=; b=x0pf8UNwXqZeLOrKOIwZXERQ/EbQMZiyY8uNY4MDufMrMEPw09gznim/gh2RSuvKRfwjtY Va5ekcc5nMd3kXTSFAt7yM50enxUv43WsJr7WqTdGnVVbx0OQ7L0x5FNXqDEPuflEw7fi8 v0iCs+6dZ4aowKWN88voJ900EElaBdQpuQhqfT3/15MNPsYWweSoOfc5XTB+m9flzDbx1h tUYHTmSYyN9Ik4Mlq4HnZ60BmJn416nFZW/apalB75s4RwSujVFe0/MIJ/I4BIb0zqp71t QglnDlqUQlLKbPGYfNZYNg/LlaXiLuTVKopZm0k/NHj4YIBnzXCr6oMctSvufA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684219247; h=from:from:reply-to:subject:subject: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=Zfmn83rF/TWm/I9paO17+6NNkBLlCT275s9VXWrN7B4=; b=/kL8pSGlM8rSLXWkrLenjE/Z1Wk3RYFekHy6Z7v8kJcVqZ7YyTsRpvcq5UMQ1KXGLqBqlH 0RuMZE6Y4b61WaCQ== To: Baoquan He , Uladzislau Rezki Cc: Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , John Ogness , linux-arm-kernel@lists.infradead.org, Russell King , Mark Rutland , Marc Zyngier Subject: Re: Excessive TLB flush ranges In-Reply-To: References: <87a5y5a6kj.ffs@tglx> Date: Tue, 16 May 2023 08:40:47 +0200 Message-ID: <87o7mk93tc.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Stat-Signature: 9965qi8yd54mmisy373oad6zwi46onbw X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4F9341C0007 X-HE-Tag: 1684219249-101329 X-HE-Meta: U2FsdGVkX1/FEx8fU/6dHHKHxajbnD/S6aZoVhZH4P3h7hwbZ3dZ13iOqxn1wOCWXE9MuSybuhka7adoPn6CLrbzb5H2lPQJnKCbPhbIZRtQVig1SIKZAsBliofFHjBlXBNIHDzX+nq924P012Xjvhfi3C4/E5G7x6ugUmfLJagsiSh1HLIdV1XnuX4oeymlzsGLL79yLjJKTLNhcxB2W0ZH7FeCoaKM5y9ekot/yjKCHGpMfzvfboYozILVPDyiKLfEYVnCyndwwRrbeg0SyjUsotwPyJJSOfo3sLocRsK4+IT/NZ1tTrSS6Y/KA0wSfO+AaFr6hWRyQhVjY4ybj38E8DRrTMb9pfIDLUnCkH8IbzWyC2c8MATtKGe3m2sfnqH+7FFFo9gMvL3JoLApQZsZBxXvhnZVmpp8C3US5YuaRW8hwe4mleriz0L7WopX70dTXVSOr+hDAXkvZGvHsBz1q2j3YT9xgqK+EXOyV6ECA0TuOGMYWWBxhUb9IXtKLpaaOeW0wiknAUXru7En/LMSRw7+5eI1Jpljt4Y1mYnZFqVfGhHt+fmr/zqjIXRyAlYIMITl6//3TXQQjcyhjpLnKTqZQq7VTVMSURGIONIHL6VbGxq4FyokXj7bH9zmrrgXQ9tRMQDBmUa5iWJDCY3vu8alhRl2N+tHvR/W8XJu1S3JEF0Jq5adaP9qboOYLmTabtNuGTz5bXuLOYMT3+GgWHcOmnjh3RxbYo25h6kpi8lkHMo6mWLAJ4OdV21863cnsT1aiO1GRrIuOzA4nqQ4wjUoGz2j1Cv1wkDk8lt8s9WFFPGJI18ltssIjXpux3f+OKhxKrmL64o3SInt5SDZceXVK5mWkieFQXsVDI1nT0ZUZYlihwgDxjrUoQP8soB1CmnmAAXGzSRiMx82bJvqXi/aLGMrPQsgBYdK/NLC6vBzWhBJDSbzCBIm0Lhe5dvrOziJcGbSwKLIjA6 lXYI/vYA udMQKqIa0XcDJAEZBqUe3vF6ENwQ2j5miW1eUBEm3gU+lU0s= 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 Tue, May 16 2023 at 10:26, Baoquan He wrote: > On 05/15/23 at 08:17pm, Uladzislau Rezki wrote: >> For systems which lack a full TLB flush and to flush a long range is >> a problem(it takes time), probably we can flush VA one by one. Because >> currently we calculate a flush range [min:max] and that range includes >> the space that might not be mapped at all. Like below: > > It's fine if we only calculate a flush range of [min:max] with VA. In > vm_reset_perms(), it calculates the flush range with the impacted direct > mapping range, then merge it with VA's range. That looks really strange > and surprising. If the vm->pages[] are got from a lower part of physical > memory, the final merged flush will span tremendous range. Wondering why > we need merge the direct map range with VA range, then do flush. Not > sure if I misunderstand it. So what happens on this BPF teardown is: The vfree(8k) ends up flushing 3 entries. The actual vmalloc part (2) and one extra which is in the direct map. I haven't verified that yet, but I assume it's the alias of one of the vmalloc'ed pages. Thanks, tglx