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 F186DC77B7F for ; Fri, 19 May 2023 14:56:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 847B2900004; Fri, 19 May 2023 10:56:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F86F900003; Fri, 19 May 2023 10:56:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E648900004; Fri, 19 May 2023 10:56:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 601C8900003 for ; Fri, 19 May 2023 10:56:58 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 33B3CC0A1C for ; Fri, 19 May 2023 14:56:58 +0000 (UTC) X-FDA: 80807306916.04.EF9CE2C Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf21.hostedemail.com (Postfix) with ESMTP id CECE21C0006 for ; Fri, 19 May 2023 14:56:55 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=c+Tku2s4; dkim=pass header.d=linutronix.de header.s=2020e header.b=Pv+H5k9P; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684508216; 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=oRoq0F2PSpeeQb/XBAm5N0UsH/ievMNugkSu6O7HCUU=; b=P3xSRDFI9ovrwy6DEbBmUR3lO4nDwrYSK5IJbgqpx7fGX4UVUvZjhBt7B6vobOJn/Io0FU wmx/agslLOhYg/OHMvCmLSz0xPOgJqaY97xd2YTo4nW/GyRI+CKxt9fqEOgOZ+/WTz9Wvo RzgxjCOJU9AK3vmTkwonznAPbaPny14= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=c+Tku2s4; dkim=pass header.d=linutronix.de header.s=2020e header.b=Pv+H5k9P; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf21.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684508216; a=rsa-sha256; cv=none; b=KpJS2lEeQqeN1J0iufWcaX4dxe0kSuKo6JWpfApu91QVESu6yew0HLs757RD+TNo10yY5+ tX7Lh8F094AVDh0HFT6RISgUTfz5h02duQ65haWnM0t3vq0lDqBOGP6qsT/7w5CmZiCvYf knH24EWYu4ORCko21MW5cDNOjIRMEPY= 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 Content-Type: text/plain X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CECE21C0006 X-Stat-Signature: 63e1e9tzds4abmd1okpp9brajk64tm4r X-HE-Tag: 1684508215-400431 X-HE-Meta: U2FsdGVkX18eKjm3GLdhMJjW72tWhCRAK1QE77PACedyCCS6c01ICHVXiUV5ZHfsHsHXsoUrUeTCZrQviJWMrjgZcJyQHbLaYpqTKcPgWxvI9tEBrArCkhNgz+WJzqMHIte7uACYMKWXFnQQ4Jkmb/dXPh7+ywqdvgZajypKAOdZQaAvTNrWjdtGnTpaAlnDgRknrltp0tAUS8CK1Ga5YdteTp7M8tHmfEyPC/tdCuibxCavJCc/7a7kq+wMDTJ+jHJby2a83mYqAoHzdJYRyuZlscCSims64dQpzCy0Pgu9Rl4QqqnvTMLKo18lwqk8UZhq/S2oc3NU1XtmB7wZrLMGp0hoQ8fuEQQqvQOCT5rod0U7145quSdolxnf4ix297rqjp5OpwR0EGpkLv8xve60+NKv6AVi1k5DqPqbQTix56GX5C5zPH9H1bGZMPaGZ8L6x9zZOP7QekNyYDw6SooDVd1flVFhB/+lJWPnJzWsnwVOQVD6IWuS97XcVSahLCbivt45ntU9u6oe5qkPwyGboQjbb5qm44mng13BHJrEmvTOw18y97FucpLFwVh41x23Oy9fG+L3aXn/GQPBmho7mu1tcg6LNO55hUTkqB8TZSdZChS22jejZfFrKsJ6Q3Js+yGWosSlbtwFXkuxa2ebye2/QmD/F35IllUQDZdCEJz52TZafP2OHF1BYYG4yibld7PQsUvGoV6ewq8j7rsrNE5TxwoEL0n0ovqMTcxk+tT03crR/NF+0fGNUkLzXaaAAJubLTBa9RSwcUVMBoVu2WL9JbTVXMwfgJtPXVILn1vqdvujSRzSVLSblHn42h16okX1Vqtyw+FTRtkmXr4z+Ceo9dzdwbb0Pm6DodTqaYO5zHh2fbyKJcr6jfSCu77M9UFcUCVE6OMRYIvA3kKFxdmDrn2FxUYq4mRtZjJeiToCZtkDBLcjTygw27Fs9Wf8M8W8X4vYC+Leu7B aXYh73V2 oZtDgbaALfGtbhahjPgp2GgqcHKRRaqkOgU5LT8OdiI1r2nly8jHiA8CUTEr6T8TDCvsE2FOp35gnYbzH2sZvlthcGI2ebNczLtqSk1/eXO0wtc8V+TQnbAgmaw== 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 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