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 47728C77B7F for ; Wed, 17 May 2023 09:38:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77C1A900005; Wed, 17 May 2023 05:38:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 703E0900003; Wed, 17 May 2023 05:38:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A53E900005; Wed, 17 May 2023 05:38:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 46C58900003 for ; Wed, 17 May 2023 05:38:23 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 14106A01FE for ; Wed, 17 May 2023 09:38:23 +0000 (UTC) X-FDA: 80799246486.11.B353454 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf11.hostedemail.com (Postfix) with ESMTP id 56FE440013 for ; Wed, 17 May 2023 09:38:21 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=iU8x368O; dkim=pass header.d=linutronix.de header.s=2020e header.b=pUISqjet; spf=pass (imf11.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=1684316301; a=rsa-sha256; cv=none; b=RWZgo/zNdWCFAJrYBDFknuyWurxWMIK6OZs2t84Cn69L9hpfkByNyO0K0FA3wOX8k4zjaL cAO9Mqk3qnZld9JT1zDaTC8aXhoWWIxO1kJ9R/HFgLoc6UhkW6cj5kMf3cluDg9k5SD3wy 3mF7zrbxlpQACvuMNJftMohOVkDMw4Q= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=iU8x368O; dkim=pass header.d=linutronix.de header.s=2020e header.b=pUISqjet; spf=pass (imf11.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=1684316301; 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=yjaTMzdhQTOgMlU5hsE9B4GGPN8OO8tRUSirJ2s2Zag=; b=m3d2BOLvZf+xMGc8SncHCXC1yQfx+4hi8ZsBkEBt7gmq4gFBa/OLrJZOZhixDjML2A/y7v EFd3AfBq7VAf+eroFX64ZCz5gDbobY2ZSfC3nZPZF19IpLtlpz/GdgXp2th1Uv5hoICrcE fZSi3QISJTycRmLqSBogVsyd07VxYcs= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684316298; 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=yjaTMzdhQTOgMlU5hsE9B4GGPN8OO8tRUSirJ2s2Zag=; b=iU8x368OY+XPAyzC9ZfApiy5XeHAOURWpyLmTQ3KlyTsQdF9EK1F8qPY4QN5FxhPQdC0aH c99C/gkceSpC+BDWIrKulnvhGJLVqU7iRx3I6MMKdEbz46LsEwudFZYZglW7iEqe86ZvTy TNYYK00aGITKTRzKq0pwy30kkjyQ4PWyoNuST+nEfgqz494H6vLx8ZeJg8dFOUFrwBG83p XeB/XEnOq25lZp4i65K5F7uqHkuXTeWPNSL1FoKD5Mbsn4nswFpe376tKPft0iQ5i+gxAy BaMkYfLtr2AfC6GIZfekahMATOy9rnZqh8YzN0RjTesy+3h+7M0cQSWdgN23gw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684316298; 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=yjaTMzdhQTOgMlU5hsE9B4GGPN8OO8tRUSirJ2s2Zag=; b=pUISqjetS+aBOeGENkFenjA8xpC5bkuzmaAXD6tMtY8GAIP+At206Pw7jxnSw2QAUI0pod z+sSygny+a9rjKDw== 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: <87edng6qu8.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> <87edng6qu8.ffs@tglx> Date: Wed, 17 May 2023 11:38:17 +0200 Message-ID: <87y1ln5md2.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 56FE440013 X-Stat-Signature: 77mspn7yr41shibu75okrs5eqa6xxwoc X-HE-Tag: 1684316301-15561 X-HE-Meta: U2FsdGVkX1/fU99YApXkKmVgourQ4i5ia4b0IGUMMaoFL8Y12Okk5K2i7vHZRm4FzslSdeUyp3SEhrrFFOYNjp7X9SGdZ4TomhTQksdOZ1Z5yZdeyPnVTX5fd/jI8MMNET4txh26JZQ7cYiT9RAXuko58uKO/8C1O8fDBGtqQ/mT3M+67k+MOLpZd/FCgm3KcEwMMGr5zIFqCWZYpacG2wNfIcoY24ZTxehgd6WoZajVP7Ir67RLmUI/HIf2WybID4sMlRfhezSOwr/q9svlCiMCm00EUsa+kiQlPk+sNHs9nqjHH9cnAZ32JPVFcyiMO3yLisX/3mjkeW1Sjxi72SViB6vZ6hDNbd4PF58CIg7hFKs86/I8Jwez+dGlMLS/fM5TWYd8dA3aT8ubqWH59vLsldS+zj/o5ZM6aa03d8l8J8P0bKN4JcnJQpWLaQJolLWK8OfiiMM4ATCzy4aq31rFgF6/g8tsColohC8j9sykUqt5pjMx/3s7B2/xmCuiv9OssrtpCsCDbDZbIHm9fzfh11ukRaUTm5H2yy4gJRtnw5stCa/dNt+ga0jZeQCcpvKsjM236hzhmvTn0stsQadGKCQwk7DkgFfU5MZ1q1zHXQ61PL7uRRQFLVD5E9PETQD79/YLZ380w9znkj9wqqnkdDFrrHgcA9hg5hTzAuGK1XASWPadg+2M2HODzpfdQGeQl7HB3epO8hhFsK9EL6ZYUV7i2++Q4HJEfdIMJhE2DlMU2L36o2bFciEh6jZ7r2Hf8x1Sy/UETgD8M2ckiJpl2axZ1Pxo3fLBK9JaJ02faO8r/NpfuYQcW49LOtplb0wXh8eFr7CvRo3ACISy4PgrSCy11XhPg4iEPcDxDFL9qCUWeL952l3d3/zV24b5X41CG+ztohzv+pB4L5JEDOQsQvMkBAP9qr9QfKOqBIsP8rHHZMnw6NGAdwCi4tR0kO2X6mrdcwaXW/jAF9d fwcxB2tp o/PDwBK8TI4Gg6Z4GPr2fvGw1afh6Vw/ZD/yO1j1VQjC109M= 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 21:03, Thomas Gleixner wrote: > > 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? Something like the below would cure that. While it prevents that this is flushed forever it does not cure the eventually overly broad flush when the block is completely dirty and purged: Assume a block with 1024 pages, where 1022 pages are already freed and TLB flushed. Now the last 2 pages are freed and the block is purged, which results in a flush of 1024 pages where 1022 are already done, right? Thanks, tglx --- --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2211,7 +2211,7 @@ static void vb_free(unsigned long addr, spin_lock(&vb->lock); - /* Expand dirty range */ + /* Expand the not yet TLB flushed dirty range */ vb->dirty_min = min(vb->dirty_min, offset); vb->dirty_max = max(vb->dirty_max, offset + (1UL << order)); @@ -2240,13 +2240,17 @@ static void _vm_unmap_aliases(unsigned l rcu_read_lock(); list_for_each_entry_rcu(vb, &vbq->free, free_list) { spin_lock(&vb->lock); - if (vb->dirty && vb->dirty != VMAP_BBMAP_BITS) { + if (vb->dirty_max && vb->dirty != VMAP_BBMAP_BITS) { unsigned long va_start = vb->va->va_start; unsigned long s, e; s = va_start + (vb->dirty_min << PAGE_SHIFT); e = va_start + (vb->dirty_max << PAGE_SHIFT); + /* Prevent that this is flushed more than once */ + vb->dirty_min = VMAP_BBMAP_BITS; + vb->dirty_max = 0; + start = min(s, start); end = max(e, end);