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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EE470C77B75 for ; Wed, 17 May 2023 09:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N1d7TcKtmXLOhob9nOFrSbSK28N/083RV3WntCyz5oc=; b=1yZRgGUjnglJ9I f/8aRZ5ChoDOLoPtvqFHCyVOpJRLgPldcrbnDVPmyUjmGJe5ods2R7+Dc3zpOXmf85hprxC7A4YXP 23iZcah+FcEiVhiGHf0M2qVxPOebNWYxqpAGhMmFIZoXwJ6ARgvuocHcLDdnSTDQYLd7naLg5bJ7a aRnIrhr2fam10syYtYRBfferviCPT3dgAoQFHojhXkvFSzKff2RSGIkMQfZWsZuGSTOT+ATn9NBhV BLu7hL7+/ImHPiP8xvovI0dNEAkamihBYXSznRImIaqSVF4zlKF7e+85mNS+cvA3bcdBG3bB70fS5 z2p2gEm8Uc7ioN5xRKfQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzDbz-0095e6-2C; Wed, 17 May 2023 09:38:23 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzDbw-0095ch-1M for linux-arm-kernel@lists.infradead.org; Wed, 17 May 2023 09:38:21 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230517_023820_625998_09348387 X-CRM114-Status: GOOD ( 12.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel