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 BA4B9C7EE2C for ; Tue, 16 May 2023 19:04:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA218900003; Tue, 16 May 2023 15:04:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5229900002; Tue, 16 May 2023 15:04:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4070900003; Tue, 16 May 2023 15:04:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B0C10900002 for ; Tue, 16 May 2023 15:04:08 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2B6B81603AB for ; Tue, 16 May 2023 19:04:05 +0000 (UTC) X-FDA: 80797043292.12.B66FDBD Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf02.hostedemail.com (Postfix) with ESMTP id B60E680026 for ; Tue, 16 May 2023 19:04:02 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=WMw1M1jo; dkim=pass header.d=linutronix.de header.s=2020e header.b=Z2djLbrJ; spf=pass (imf02.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=1684263843; 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=/J+XUgJdREytt43ELVIV0Mmf1u3JBQgXoDKhW3plfNk=; b=L8H56Rc0kzP5Q2ZvDdsMG7s9UIaXHYimiywckX8t62dLgmzmAm+jwtdyhXbAsZjDTzldU3 OJ6JcHzqSvCikrWIwns851d2PBSm8LZ7K16wt6BOg5w7hx0e1c3DknvvLVtwa/4Hfc3roc 9ygS0+c/t4Nk1gGitMbmmnCFels57/o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684263843; a=rsa-sha256; cv=none; b=E0v+8oH7Rdt/FMjKxRj718lrMsitfOAqxPdIitOlRcDfoeGv4OPFmR15vf6ZeYmxVW6UdE 7uusDBh2FFOQy2nHy0awMyK06doxRAZL1H5lxgfO9EJ5LIOPvq+G0lh8UMDX0qw7wGqkxH Jez+J9giAs6/dvx3okvnKSb6F1se+CI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=WMw1M1jo; dkim=pass header.d=linutronix.de header.s=2020e header.b=Z2djLbrJ; spf=pass (imf02.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 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684263840; 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=/J+XUgJdREytt43ELVIV0Mmf1u3JBQgXoDKhW3plfNk=; b=WMw1M1jo9bhdeSKpJe5F8KE/HLWYtQXZu3MZqTsog+pqRSLfado2Ppfnl+oTirMNl8Z9M+ kfRvAe/OPZvikGVtdWri5TC7WId+AsdsmfSQ5Cwd15lrmXzxuMc9moijwaL5LLEvLGqWBZ h5gcQRzKuKtn1ZhJ5Co6mtB+nWDnZpGcG68kBiS8rL/2QK3wod2NJAUk12K1W3nMwEQrQ4 P1aWPnS0vHxmTtqFkDn/fTq+tTBz6aF0gYbqGBGP4jWk5YHv7e+I4rdgvHrbEIhnjjIlCl 1M8MsN7VtlP2WHDCqEq+IkSjvq7AfFotD+GlxK881bOqH1DN3j2osPFbcZSyqQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684263840; 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=/J+XUgJdREytt43ELVIV0Mmf1u3JBQgXoDKhW3plfNk=; b=Z2djLbrJ6E2dVYd24wpsCGv25mFwkGUngwVNkFTX0zH4v5ch8IZizZJQFgpcU+8hl0pTFg 0X0a2vUFkgcSACAw== To: Baoquan He Cc: "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges In-Reply-To: <87r0rg73wp.ffs@tglx> References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87ilcs8zab.ffs@tglx> <87fs7w8z6y.ffs@tglx> <874joc8x7d.ffs@tglx> <87r0rg73wp.ffs@tglx> Date: Tue, 16 May 2023 21:03:59 +0200 Message-ID: <87edng6qu8.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: bkcz7dhz8mzbq911qxzqeh16kqkc3q3w X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: B60E680026 X-HE-Tag: 1684263842-124252 X-HE-Meta: U2FsdGVkX18zLPKw4Ndb7T0loIXQQP0M4bS7mRoh+radgHK7R8B+1/ZjpKUbdj1mWwDEVbBUUVcC56xYIOC12Qw83taSsQM2Pv8JXEMww6VE+um+K70UI1xmqy6mKwTu8XU3MhQRdCXAKxbQHWX/OzsyfPv29gk7JoB7SpaCFBaBKGCD8Mv5ZKrQ9ILDYSvmWFAywiVCZmscbuicBHlQyc7TxDE9xbCagd+QKeCidCZw6Nnsww8OtdfOqM6Aa0JfrKXaEm/+fBTx06a4IDBmI79sbOi3hyJE5A05TwaeJGymP/naCbe7IF6E1y4c88q9weLd95xgTtArM6oadrIa7HUp58uJ1dUNTZ3qeWr+AQ20dyGzpEViee7FForqgcCDpItq3H4dFAGJrwNDBZns1jiNeo2r75CjXQF31DG7f6efZk8u74tPql9WljXEzheZGLiw8/dnV6Af8HbaKavxvWu+KgQDC3dHuOgtcG6gBlY97Qrak9KRbV4QGtv5iW+Rnfcwmpu/E2lOJ0JHOfyvw0aoRAUVMyHBG6eGFjXk6bVXyp4JrlF9E6pDMGE6t4rmHLEDPRdp0RyAFZ8Ba0fIcfy4b3CSaYds5FSBxWYC+MIfik+q1MMKArRQzceW4bvYb643b5pWcWdUXg9BE8CK2KhJIhmTi/UgIeR3z/P6GWciBR4aLmWIjD5GU8kcjfNfCPaKb4uysWSeqeZxrrDsaMjTQwOCqFoWfG0tHW8F9Qc+9ZNwwiK7DEHcd7R5TOXJYYeiMQ4d4YeKIEtuXkBwqwmQyskNB06oCXDCvgsAy4ltgJggNpUxhkoPBwR64B9rQUTDjayOG5hTwkzvQvIP+ukqTN1/iQQtogDQgW54gCt6hX0BEQ24at2nAB7mfHw+YVhZiHiJttjyLkuBXGRejLp4+isF4b4vAGRYuojmEdb1UqUKoDebRb/ALrv7xMIfUw0BY0j8+XYFqQmHY9C hf6h2VcF 8wkY/mm3/9y9EKgb4CpO+2rp2HjThRaNztpnQGCh11jh2hp8= 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 16:21, Thomas Gleixner wrote: > On Tue, May 16 2023 at 18:05, Baoquan He wrote: >> On 05/16/23 at 11:03am, Thomas Gleixner wrote: >>> static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) >>> { >>> - unsigned long resched_threshold; >>> + unsigned long resched_threshold, num_entries = 0, num_alias_entries = 0; >>> + struct vmap_area alias_va = { .va_start = start, .va_end = end }; >> >> Note that the start and end passed in are not only direct map which is >> alias of va. It is the range which has done merging on direct map range >> and all dirty range of vbq in _vm_unmap_aliases(). We may need to append >> below draft code on your patch to at least flush the direct map range >> separately. > > Indeed. Missed that one. What a maze. Staring more at this vbq handling in _vm_unmap_aliases(): It iterates over all possible CPUs and accounts a range when if (vb->dirty && vb->dirty != VMAP_BBMAP_BITS) so that it gets flushed, but it does not modify that data at all, so a concurrent invocation on a different CPU will see the same ranges and flush them too, right? Now after this loop _vm_unmap_aliases() invokes purge_fragmented_blocks_allcpus(), but this time under vmap_purge_lock. purge_fragmented_blocks_allcpus() iterates over all possible CPUs once again iterate the same per CPU queues in order to potentially free blocks. I'm probably missing something, but can't this be _one_ loop which handles all of this under vmap_purge_lock? Aside of that, if I read the code correctly then if there is an unmap via vb_free() which does not cover the whole vmap block then vb->dirty is set and every _vm_unmap_aliases() invocation flushes that dirty range over and over until that vmap block is completely freed, no? Thanks, tglx