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 C66EBC77B7F for ; Fri, 19 May 2023 14:57:20 +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=GmXMQgOgSg/u1GHRe7/nrj9E2mSTnIbskIRmqPPO/n4=; b=W7EuXQopOKiVs3 W49RAx49HbRmVZc2HW+agtnH56NuK4qvw7cVFuO4MMEH5pcfUmmnQQ7QTq7WVAIRIBYamWD77sAOO XojdL0ocX7sgHoDLW91kz25YvqZsNTWpc5faro6Wl65bQXuisWcIKtI3A+nYFU3VLEiBZ8hIORnQV 1tbC/HpyqFxw+CWH6c3m953zVy/CdmSYgJznyMNCslkyxqudBMOEv7y//+DdlUEYkpXJZe1vViRuG z6eMW3FCe3Fb/sFQpCDIx2+bV0ze3qKcudYq/CYy5cLPAzQptiJp1VvV/QrPrvV2+hcFiJUE9Sg5D ChiVbNj/pAPosmEaLhBw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q01XP-00GX8e-0z; Fri, 19 May 2023 14:56:59 +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 1q01XM-00GX7V-2t for linux-arm-kernel@lists.infradead.org; Fri, 19 May 2023 14:56:58 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1684508213; 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=oRoq0F2PSpeeQb/XBAm5N0UsH/ievMNugkSu6O7HCUU=; b=c+Tku2s4JPsaMlfMb4vPOW1QraJpnOakafOYkNdlNx/4YBCq+4iRerGjYTr+PUgKVlFHPc A2dvChZynHRf1xoE6oRMAYNB2dJhQM69/dGgHUY2wqThU9vh6vhdzNbXW5KwlSyMnMG6aa Q1Asap8LPYfOOWuG1MDql2akoetAg7fBLWYECWIrAxKsmoM59w0q3wHCF9ACWA+z+nm0wA msSTUnqh9djlKUF5wRKPXhkk1gc7YNwoLfZEo1UW+4zAOhu+QrWdmeIax29wttl62cdXvM 7VI02tpwOuXtMZSKRPi9c15I01AVcSGJMsqbPuZV26An+T2V1HwflRfYqKHd5A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1684508213; 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=oRoq0F2PSpeeQb/XBAm5N0UsH/ievMNugkSu6O7HCUU=; b=Pv+H5k9PXCvMvKzp1aY8e1nPMH0oQ0yvxjbtWs0yh37l97hgREUEDN0fgPr6Dg4KrV2Sd7 QutL1EKnzx7AnBBg== To: Uladzislau Rezki Cc: Uladzislau Rezki , "Russell King (Oracle)" , Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org, Nadav Amit Subject: Re: Excessive TLB flush ranges In-Reply-To: References: <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> <87leho6wd9.ffs@tglx> <87o7mj5fuz.ffs@tglx> <87edne6hra.ffs@tglx> Date: Fri, 19 May 2023 16:56:53 +0200 Message-ID: <87lehk4bey.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230519_075657_073492_8290715F X-CRM114-Status: GOOD ( 15.42 ) 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 Fri, May 19 2023 at 12:01, Uladzislau Rezki wrote: > On Wed, May 17, 2023 at 06:32:25PM +0200, Thomas Gleixner wrote: >> That made me look into this coalescing code. I understand why you want >> to batch and coalesce and rather do a rare full tlb flush than sending >> gazillions of IPIs. >> > Your issues has no connections with merging. But the place you looked > was correct :) I'm not talking about merging. I'm talking about coalescing ranges. start = 0x95c8d000 end = 0x95c8e000 plus the VA from list which has start = 0xf08a1000 end = 0xf08a5000 which results in a flush range of: start = 0x95c8d000 end = 0xf08a5000 No? > @@ -1739,15 +1739,14 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) > if (unlikely(list_empty(&local_purge_list))) > goto out; > > - start = min(start, > - list_first_entry(&local_purge_list, > - struct vmap_area, list)->va_start); > + /* OK. A per-cpu wants to flush an exact range. */ > + if (start != ULONG_MAX) > + flush_tlb_kernel_range(start, end); > > - end = max(end, > - list_last_entry(&local_purge_list, > - struct vmap_area, list)->va_end); > + /* Flush per-VA. */ > + list_for_each_entry(va, &local_purge_list, list) > + flush_tlb_kernel_range(va->va_start, va->va_end); > > - flush_tlb_kernel_range(start, end); > resched_threshold = lazy_max_pages() << 1; That's completely wrong, really. For the above case, which is easily enough to reproduce, this ends up doing TWO IPIs on x86, which is worse than ONE IPI which ends up with a flush all. Aside of that if there are two VAs in the purge list and both are over the threshold for doing a full flush then you end up with TWO flush all IPIs in a row, which completely defeats the purpose of this whole exercise. As I demonstrated with the list approach for the above scenario this avoids a full flush and needs only one IPI. Nadavs observation vs. the list aside, this is clearly better than what you are proposing here. The IPI cost on x86 is equally bad as the full barriers on arm[64]. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel