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 DEFB5C77B7A for ; Tue, 16 May 2023 19:04:24 +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=mcaBKOPbVxhuFVzcQ289HSNYO/orQQ61uqljgxXzZ0Q=; b=w6I0R3VrFcpKyo L7c23Tzd0eeM2juQNqEbuhLpMRN/LNR8fMNozmB1GrEceXYMOZu9Xe6xF7wQ+CbJbZeb+7k0nkZPs Cs0JXyOZW+3NySCeUYbi31qe1At47sFose3QgO+35cNRrGAainhIqLesYc16IvFgOMNuwxv5dtVb7 ymwHIjb3Fn6WN9n2QyPmy8eYpsOor/1UHjPFEqcJ8YiBNEzUjht/7X79pL3ik4ehxoMNdzqy7+eRD KqPRI3BBTMcHYW6PH0rNl2SG4CQAKTvsgTALXi0CibdqS/KvWRkzDSs/iBpoxWcvTO0fN/ilMduDg UJQx/70adydpOBg1PCkA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyzxs-006rH6-23; Tue, 16 May 2023 19:04:04 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyzxq-006rFP-1y for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 19:04:04 +0000 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_120402_789158_C91D8AF0 X-CRM114-Status: GOOD ( 13.52 ) 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 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel