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 9B54EC77B7A for ; Tue, 16 May 2023 08:19:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F308D900003; Tue, 16 May 2023 04:19:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDFD8900002; Tue, 16 May 2023 04:19:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA7F2900003; Tue, 16 May 2023 04:19:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C8900900002 for ; Tue, 16 May 2023 04:19:42 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 97308AD817 for ; Tue, 16 May 2023 08:19:42 +0000 (UTC) X-FDA: 80795419404.03.F0F67DC Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf06.hostedemail.com (Postfix) with ESMTP id 8E15F180004 for ; Tue, 16 May 2023 08:19:40 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=txNr2DtW; spf=none (imf06.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684225180; h=from:from:sender: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=GpluGkfdMfUAqluklwPhF8EJ0GGm8Xs93dMxjtV521c=; b=y379TTHl8PY7yE6fGzKSdm/dzh1CZU0sW40mmVa3D94IyXvUQgl8NsPQOP4XsZhj1LIwFt ZC8ctedHnnF7NJfIc3q2dV0hNScJnf35Nuh4LfuyLVhTk+x20rUn23w6iJwSj2+eA1y91T hDdYXd5kCzBLPGppykFnv1A0qCYc8kc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684225180; a=rsa-sha256; cv=none; b=PtvD/5iAB79DZ5sOwPUOCImaPTa1ZLugwt0x78WSjD/89VZ6v3qch7WR4fep+s+gmeUi/4 hTf31173xLjwxVpyZRGoeCMSZrsw6HrR0HQnXWevSqxunfgc1ejyrYAiEYz2ousXpqt2rD xIHN2hVjNfbO04UxMg+sTxa7nqNP6WU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=txNr2DtW; spf=none (imf06.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GpluGkfdMfUAqluklwPhF8EJ0GGm8Xs93dMxjtV521c=; b=txNr2DtWs8k8wHTEgrTrwbBh9T 7bcA2QjhcXm4vu7dQsoM7MJFNJWvyn3Qcs++Jir+Hc6cKlvEh6BGIwpMToN85mrpguvb2qlyMs6H0 OeOxRgqtlKXPdTOpv5ot034WsLmIWJSKXdJYrbTTTfkad4O79TywwLPa/3bJedL2YJRL1IEYQvD05 m8dO8hEpfSD990HswsxAYxwXocvC734MF2g9cOBaUyfzbBdeUPmkiqQSTM6Xi5KO1QfP+4xjlxfFH dgzo0gwcAlbV500p6N44D0IHWZyibsMsS9Iu+f6yPeSm7LMgCQ4cCjxUA+bLWps7bhB6bMzgy88hV mY0GoVoA==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:49996) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pypuB-0005LR-Dg; Tue, 16 May 2023 09:19:35 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1pypu8-0000e0-Jb; Tue, 16 May 2023 09:19:32 +0100 Date: Tue, 16 May 2023 09:19:32 +0100 From: "Russell King (Oracle)" To: Thomas Gleixner Cc: Andrew Morton , linux-mm@kvack.org, Christoph Hellwig , Uladzislau Rezki , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Subject: Re: Excessive TLB flush ranges Message-ID: References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r0rg93z5.ffs@tglx> X-Stat-Signature: bop7pshz316o9eb96ena57s3cgm1qgjz X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8E15F180004 X-Rspam-User: X-HE-Tag: 1684225180-626351 X-HE-Meta: U2FsdGVkX18zrO7dATtrxn08NEaH8Vo+B6bQZyhMre8Q1zbrhAy3EQbIZcyDXtAno2QJBarvEO8n6PxrHDnKggpN6uf7pWrVLdAg0pGy2LUmzfyWjkb7D4vzN3sx+j581Oq6IIVgPlvKDKgMVhQGGYfpMDsOJ9hZrt9G4V7wjBnsleVdOZZLErP69aKx4VW6xp7ZO28vyG3WeoZfdLn2igbD73yo7k312ck4Hmr1/kOyToFGTgAWHHoYmVWPLHTGxoQTwT4sHHeuypgSg7sRRs7fxFUuZFIFRn9GQDFMLDfCkSzy45pHZmMpJfez45kVkyHuD8rsQekPVEColthA4/zW0KWghjn19PcmYNf0Fd831i47bl3wmRqpS7QFor3lCNEMxSfopYTyaWL+2zqkXk9p+2Z+vm2WUXlI+hAJAOXCF10Qv8jcXg1nhl0ay862eooztdjtageLCa0kjBzKKvMWtPLmKp09Au+coMRwAzZ75992GvZMV/iyyRsPxPwgU0ARp4RFaSo33l2MPyLkNNdsoEmjHcdmzbQ+THWApFjjqi4m6Tkn6ZoQwFEzHLeqS2iBII6TX72COJsjN2hZ+npZqyKV+C33uiL91H5/CtvQ6BbcuDMTKKNXi06Agv7C4Cjwez0O9uWyKPe+t05O4rvWLACD+uDfY4r848rF/aTZQVFG/phdcaeniTfsT3x4kKL4C4Ks5oxNemrguoMpRO4oMcVVOyBvr5DAIDkLu30hTU83cRWnZUKCvHwm/K+dshISBIChB328+wRiqlLSx1+tN12NWJJtl8fhV9BjXWnlmcVrzCduFauImz+xMcBK8FHPEbfSiU/qZQ7KdjBO5nEDJq9jr2adIEF2nTLpqyfsaocJUpYLfB+yPYMkTQSfJVclsT+OOM1mA7ld2Aimcc8uMCaMA/bumikk0hkk3v7Bu4moXbaq9Wbe2yS6G7pXlkzPcdP+6OEJU2iMy4L EzUDZgPv DNMlrnI+znXdfmlXlbEzjunaxy2HGYsYyIl0tlcj4oP7XIxOhnYUGgrlhFICdtu6bcJ2Wn7ptcBe1xcIPHgUUojxkoaVm0WQS9KI6aATfELFPhGwn8c2f5Q/BNWArJMhwuOtShVVkIxk7+cPoa9cmjRosEnRrzN4vM6nxWiscR7YeBlzs5ySlgxdFZAUGkjtCf6hD29axHZJu/SVn6rcfMOVdI36SbiekT13MvqX05gZfc2HarTQ90hdwCN/fr5znOtZBERJ5LVZM6N/a6ZGRrSvHmigOYUCYdU7bUtkZGZIiHzHVylBSs2okWO//wn3rodGRgKBQECyyJZzI7610bb5Oa2he49wEhGY56jl9XqfG4FqqOSbz6Kf9ttU0SdKQEcyrCurSL1H9bziq5fgzM84mwPLnN+RKN0M5tpxqYp06gt7CmM2eDHNbeWEJIejKQQFYeNOfbzNlA8wJANsWPCZzPXrr+kV0GKtFtItSWVkxT7mcNQkWF7VAt3NiJhCDFw4I0DO/l60iOmWrpGP7fTvj1VYObAjEfUqVQM7zABTnC7Kl4UYfo7H8Lw== 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 Tue, May 16, 2023 at 08:37:18AM +0200, Thomas Gleixner wrote: > On Mon, May 15 2023 at 22:31, Russell King wrote: > > On Mon, May 15, 2023 at 11:11:45PM +0200, Thomas Gleixner wrote: > >> But that's not necessarily true for ARM32 as there are no IPIs involved > >> on the machine we are using, which is a dual-core Cortex-A9. > >> > >> So I came up with the hack below, which is equally fast as the full > >> flush variant while the performance impact on the other CPUs is minimally > >> lower according to perf. > >> > >> That probably should have another argument which tells how many TLBs > >> this flush affects, i.e. 3 in this example, so an architecture can > >> sensibly decide whether it wants to use flush all or not. > >> @@ -1747,7 +1748,12 @@ static bool __purge_vmap_area_lazy(unsig > >> list_last_entry(&local_purge_list, > >> struct vmap_area, list)->va_end); > >> > >> - flush_tlb_kernel_range(start, end); > >> + if (tmp.va_end > tmp.va_start) > >> + list_add(&tmp.list, &local_purge_list); > >> + flush_tlb_kernel_vas(&local_purge_list); > >> + if (tmp.va_end > tmp.va_start) > >> + list_del(&tmp.list); > > > > So basically we end up iterating over each VA range, which seems > > sensible if the range is large and we have to iterate over it page > > by page. > > Right. > > > In the case you have, are "start" and "end" set on function entry > > to a range, or are they set to ULONG_MAX,0 ? What I'm wondering is > > whether we could get away with just having flush_tlb_kernel_vas(). > > > > Whether that's acceptable to others is a different question :) > > As I said flush_tlb_kernel_vas() should be > > void flush_tlb_kernel_vas(struct list_head *list, unsigned int num_entries): > > So that an architecture can decide whether it's worth to do walk the > entries or whether it resorts to a flush all. Is "num_entries" what an arch would want to use? How would it use that? It doesn't tell an arch whether there is a large range of many list entries, or a single entry covering a large range. Wouldn't passing "start" and "end" allow an arch to check for a small range, and if the range is small, just call flush_tlb_kernel_range(). If the range is larger, then it can walk the list to decide whether it makes sense to flush by list entry. If it deems that it would be too much, then it could then flush all tlb entries. The down-side to that approach is its more arch-side code of course. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!