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 9605CC77B75 for ; Fri, 19 May 2023 15:15:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C624900004; Fri, 19 May 2023 11:15:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07747900003; Fri, 19 May 2023 11:15:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E804C900004; Fri, 19 May 2023 11:15:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DA6B4900003 for ; Fri, 19 May 2023 11:15:05 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 94D96C0299 for ; Fri, 19 May 2023 15:15:05 +0000 (UTC) X-FDA: 80807352570.12.14975EA Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf20.hostedemail.com (Postfix) with ESMTP id 84CA11C000A for ; Fri, 19 May 2023 15:15:03 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=PC45RYhC; spf=pass (imf20.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684509303; a=rsa-sha256; cv=none; b=fQxlz6exD0KlFAte9FtRERK2fxA/6XYFWmhXHvNOroxS9Qwg6q43W3C5MFvQgfWhE0k1yI Nvh+CS9meg4rwolQ7bHnJKx8b4xkdY8sgdjvRmGpnGzbdvGg5O7wAIVDt7RjoRsVkTfaW1 ni7abTYXYrKKOgqdazXTNGaipY/GEaI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=PC45RYhC; spf=pass (imf20.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.53 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684509303; 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=8e0yuqMeH77y385bGplR435cEZnwX7M3pem8aqlOD6A=; b=u2LKnpGZ7j3mbdmLZy5Qw9SdlkRf8iVuvRHkY6cdHtg6ZfPGkRH3OJWe6QbjcWoRXpuOhd 7qoPDXdCh72szxK87/fO4OdLOgkUEfWe/SyR09u1QV5VrEWds2QAW791Rri+GqWmiIia6l skWEko8c/xqViLO/NBVnYZzgi1LTR3k= Received: by mail-lf1-f53.google.com with SMTP id 2adb3069b0e04-4f380cd1019so3995034e87.1 for ; Fri, 19 May 2023 08:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684509301; x=1687101301; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=8e0yuqMeH77y385bGplR435cEZnwX7M3pem8aqlOD6A=; b=PC45RYhCU1F0/YsuxOc8oLePK8BRR/RpBAhY9uhKd8bJVOYLSroTsB2S23sDYEf9IU RKBXYztUznogYGoA/yOEdcPcIjkCyj8KDrwrECfbwvsmAgV85wZKTz7+OxDpoguK9aDV dNurrCoG3Zamyi4VMtkqlNQ3VitCXIt7HLdO0adExuBLqCoN/MLpLef4Ftbm9LZ4yqDw LBYf4FIVVAnz73Dt2AZPwWBG8SN1GV4ZV3tF6hRGoPDPdXi8IFdjINT3sZPXqya9JEaz VMuc9P7XWeCr5vtJhprVGS243g2iAMdFK5eHvxkReYyB6hDlUKmljmZUgAeSIIAgJz60 b0IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684509301; x=1687101301; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8e0yuqMeH77y385bGplR435cEZnwX7M3pem8aqlOD6A=; b=NIVJKE+ovCtCPKEfga7GUqfivdd7zheq4X+dLKPgcbLBN2KhNm+NdZMOKXPTiA6EYK NnN1LDWVyFKMcurNeR/zvtcBGn2u/KjGY6WI/Up0IECrgrEMrtCpisPw4j2JmcOve10/ vWa2NSWEbXMSQsAtl4G9yR3Y//Q9K3SD1SoTtxqGLo2ChHvVvF73BslEILykdHIE9QCU U7gfSH36Sv1yF4igraZrlWewc0BB6c60EeXIMMIHw0mUo5qBQh/pXma9yresvXbmOCqv I8Tgg/BYzrnIdtreHW65H0xKnHy0hkV+qTknwouYhTEwKBN/zKP/kglT0+9ZoyykO402 Cp8w== X-Gm-Message-State: AC+VfDy3AFXNKTBDDEG9l5ZLP8+SCZFI3WLjaOtwemZw/q36AEAFjdfl ydjoaMLFkYoGkFUxjFIfJbU= X-Google-Smtp-Source: ACHHUZ7DUVYf6J9MIyc9ieuAXvzosS2fWbEpipG/OTZ5pUkMR84024z1M04pG54QVB6zrhoENipJmA== X-Received: by 2002:ac2:4430:0:b0:4f3:a99c:fbbe with SMTP id w16-20020ac24430000000b004f3a99cfbbemr1027456lfl.14.1684509301240; Fri, 19 May 2023 08:15:01 -0700 (PDT) Received: from pc636 (host-90-235-19-70.mobileonline.telia.com. [90.235.19.70]) by smtp.gmail.com with ESMTPSA id i13-20020a056512006d00b004eb44c2ab6bsm619596lfo.294.2023.05.19.08.14.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 May 2023 08:15:00 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 19 May 2023 17:14:58 +0200 To: Thomas Gleixner 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 Message-ID: References: <87o7mk733x.ffs@tglx> <87leho6wd9.ffs@tglx> <87o7mj5fuz.ffs@tglx> <87edne6hra.ffs@tglx> <87lehk4bey.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87lehk4bey.ffs@tglx> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 84CA11C000A X-Stat-Signature: gugj648c9fqmdbwfok1qnoma6ijjqyx8 X-Rspam-User: X-HE-Tag: 1684509303-911140 X-HE-Meta: U2FsdGVkX18y9FYdN+0Z4OhiYgpjzF2NcgNuC1zIGPIwaNug1MPPn8BQZ5a9T1HU4FVoXLivIr7fw46cMtmWUri+nvFBy0QzA27Svk4vVZt+xHcrRm8SasMM1DbSVclspO61akpIqytUSt3TeUevKj2nbl4TXmaDMyvEGK2vsd+qIYL6iTCeUA3+f7lGxUxGPBZxEuejqWXQQBFlfvC5P1zk+QA6S7regclyfGhSS0XIXEGwScCT/K4v5A58Yzl0gR/X2nYO7RwSZhroiMqvzX820GCcC6W0AO4CLW5vUT5rvzoi6RSs5Zjnt/Ik2t2UnGh0wzgT5JHy6Zj8aXYkkagZsG4Z/0cnaVPzIJXaMNe99VNvScckoynYgUKwo4ZG5wan5U2EO2YF+8k2AnVkXMXWr3GoR82i+irRbWS5S9JCIEpjN4UanIHDXzuUyVbLtw8Qh07MfMMDiMEcSoAv9yLYxTtR2wnySWZTCqNGdmFz8/CmHgCRWzfCj6X/JY7EDumxa07CHWTuzeTxnPWIa71YqEHogGJBBxEgvqdMz8H71bpZXFCgNf807xYhPthXLZy9EXgfbAyZPKyCzZe6FK9zLOQmVm8Z5yrgm+Jn9R17NbZ2oPI37vaxfvJbX9CfJUklrHnMUVZnoOxS1b7mk7PDOkOXwy9VBShDwWSVp+ze1OmhktcFQJP1juBj6ZrgFaj1woAVt0BZWDJvGWcbtncggZqOGo4pFBtxS0rMxYmF4YClx2jqswTnnT2RcFayIRReTdDezRbUxIvXdFEGWH5q8edmQYQ0ozN/hIwaDYW8Et54vnKuHJ/IRVJWu1zAahpJUNqf+GX1mm3lsZMsH3yJ79XoP2LRtvwdcbNcHZqYNuT8eX1O5RS7bBmvDP97FM7WriaHwgG8opTB2Mc0jsOd9H4wBYbnK/vyC63oRBeGq1Mf+iq+BoXBFcvfzl8vP88DT6rYz38H7zfXqXb xMZSx1MH y8wyxWh4dGBc3DV/XNs8Ts5hE1mQUjLh8QVkXcULEqJfwoo+AL74ZsKDOYVx6mViHt8cxGYbfX7U2fTm34pDaqSh4B4ABn50+2MY6dPbhODB99bXvYLj+fYI1O7DBD4St+rmWB7aFCUgYPymAXAJ+karnXg2zujpQOyMOYofHrCzhGxSCZzAW2ILWquQMUe1F4TrooDDvHe5+8rhJqwC5b0BYZ0C4OP3poF3uE1S2ujQc9LHCFir37nZBtx+INWpXI5ZNFl5u2WSRF5VPW3ZKsVT/SD0j4OwWp1se48X9B/DrYhdiYdgNpLYvZVzYf4PPDeun+PItUdzkqALvIFHaV2s4hRoOYfs+pOho+6MrnAAlNzBQ1LtvmPHkLgqa7/UaCbsZ/HMd7fWOj83uipUgOgZOfnYV7A3YHdjIo3L3JlonIINW0X6qJvFWcbkDJbvA8o+AKqCGPjyU14Cdfb/jOSz3TtFPS4vyWIlTxHidFHqUgeW9008wWfXBFA== 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 04:56:53PM +0200, Thomas Gleixner wrote: > 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? > Correct. 0x95c8d000 is a min, 0xf08a5000 is a max. > > @@ -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. > Absolutely. That is why we do not flush a range per-VA ;-) I provided the data just to show what happens if we do it! A per-VA flushing works when a system is not capable of doing a full flush, so it has to do it page by page. In this scenario we should bypass ranges(not mapped) which are between VAs in a purge-list. -- Uladzislau Rezki