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 7D7C1C7EE2D for ; Fri, 19 May 2023 11:23:03 +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=Jh2aj8cCGWvYtQyJj1KJFO7jZBd7kDH85dSILrgHeos=; b=rUXWDlneuBfPik EUlFWZ3oRihhxqDrv84+jSyWWUuux1AXl05vLR8VUbJnFLZ8MQ8CkpirGPa9YoI7xsxEJ6lXyzkVA HAWnNoiMKTF+3KosR4lvNPtuH2wO73V6N14cw0T2T29MtVtzUBDsUn3a/4cXfmQ5Cfm5Xr0Iq1ozZ 8acAH86wNRTIIidVU6xN/Oa1XkN8DvnxB0Bh7SYCFwbgQF4r5xHgJFsq4Nx7FDUsUHBuS5+Cdj99W V606c5YUznqu8hMiIYFYXw9dyx4mAi2SQno1Fa3AmB3mVf5yPhFcjRw+EMpkkuxCtS4/CDuLC7wN7 SFfWQoCOmcAI4DHsDRfA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzyC2-00G5lU-1R; Fri, 19 May 2023 11:22:42 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzyBz-00G5iP-2E for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 11:22:41 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684495354; 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=CncQGef04JUgDq7mqlEvPuIrbShhxxJ7OVQbbGI31JE=; b=J5xOrLSCCAFrQj5XnW6TUc+BlYiyF9T5eKjv3yslaDq2zFaCYtsFS/2jnRc72w6hQOvf8p RaOsk+BM3jTLjOggLh7+492mmQaW5Dwbwj/6ipLV5vxeg5s9HRS51KmlgKcBpgfl8NvheW NEKXsTt2yhWIiWA9bWnBVfBClPuSGYfwc/HTup5TGBzlNCVsTOBfHgsZcsQJhXHsC0JdUg UZyr+0YioyrLoTLn6MkLEQWMaArIs3tY3NXER8VSMPKnmf9jOhuWfl2ZYFWyf30dvr01z7 SDe6uSn2p07WR2BmqTswt31NBc/V/lPbWaAVgek7omsG9WGJ9DP2/UgWE/5u1A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684495354; 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=CncQGef04JUgDq7mqlEvPuIrbShhxxJ7OVQbbGI31JE=; b=xwm2CWlc2UZLwGaeTYYC8E3P2PS1EQrdXfNfS+PTEXQiRoLKxJgoNVxSVdoInmf7IYjbPu R8uI3pezSRwRbZCA== 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: References: <87r0rg93z5.ffs@tglx> <87ilcs8zab.ffs@tglx> <87fs7w8z6y.ffs@tglx> <874joc8x7d.ffs@tglx> <87r0rg73wp.ffs@tglx> <87edng6qu8.ffs@tglx> <87y1ln5md2.ffs@tglx> Date: Fri, 19 May 2023 13:22:33 +0200 Message-ID: <875y8o5zwm.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_042240_043139_B580F00B X-CRM114-Status: GOOD ( 23.28 ) 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 Wed, May 17 2023 at 18:52, Baoquan He wrote: > On 05/17/23 at 11:38am, Thomas Gleixner wrote: >> 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? > > This is good idea, I am thinking how to reply to your last mail and how > to fix this. While your cure code may not work well. Please see below > inline comment. See below. > One vmap block has 64 pages. > #define VMAP_MAX_ALLOC BITS_PER_LONG /* 256K with 4K pages */ No, VMAP_MAX_ALLOC is the allocation limit for a single vb_alloc(). On 64bit it has at least 128 pages, but can have up to 1024: #define VMAP_BBMAP_BITS_MAX 1024 /* 4MB with 4K pages */ #define VMAP_BBMAP_BITS_MIN (VMAP_MAX_ALLOC*2) and then some magic happens to calculate the actual size #define VMAP_BBMAP_BITS \ VMAP_MIN(VMAP_BBMAP_BITS_MAX, \ VMAP_MAX(VMAP_BBMAP_BITS_MIN, \ VMALLOC_PAGES / roundup_pow_of_two(NR_CPUS) / 16)) which is in a range of (2*BITS_PER_LONG) ... 1024. The actual vmap block size is: #define VMAP_BLOCK_SIZE (VMAP_BBMAP_BITS * PAGE_SIZE) Which is then obviously something between 512k and 4MB on 64bit and between 256k and 4MB on 32bit. >> @@ -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; > > When vb_free() is invoked, it could cause three kinds of vmap_block as > below. Your code works well for the 2nd case, for the 1st one, it may be > not. And the 2nd one is the stuff that we reclaim and put into purge > list in purge_fragmented_blocks_allcpus(). > > 1) > |-----|------------|-----------|-------| > |dirty|still mapped| dirty | free | > > 2) > |------------------------------|-------| > | dirty | free | You sure? The first one is put into the purge list too. /* Expand dirty range */ vb->dirty_min = min(vb->dirty_min, offset); vb->dirty_max = max(vb->dirty_max, offset + (1UL << order)); pages bits dirtymin dirtymax vb_alloc(A) 2 0 - 1 VMAP_BBMAP_BITS 0 vb_alloc(B) 4 2 - 5 vb_alloc(C) 2 6 - 7 So you get three variants: 1) Flush after freeing A vb_free(A) 2 0 - 1 0 1 Flush VMAP_BBMAP_BITS 0 <- correct vb_free(C) 2 6 - 7 6 7 Flush VMAP_BBMAP_BITS 0 <- correct 2) No flush between freeing A and C vb_free(A) 2 0 - 1 0 1 vb_free(C) 2 6 - 7 0 7 Flush VMAP_BBMAP_BITS 0 <- overbroad flush 3) No flush between freeing A, C, B vb_free(A) 2 0 - 1 0 1 vb_free(C) 2 6 - 7 0 7 vb_free(C) 2 2 - 5 0 7 Flush VMAP_BBMAP_BITS 0 <- correct So my quick hack makes it correct for #1 and #3 and prevents repeated flushes of already flushed areas. To prevent #2 you need a bitmap which keeps track of the flushed areas. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel