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 D3968C77B75 for ; Tue, 16 May 2023 15:03:03 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:Date:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=l+WSOj+w9DF/AogXrc1Lq7zU5wijribsqtIYz1heWaA=; b=ZnhiasUpju+W5N Bjd0/M4vzwVHKYlUR+jRiE4J0BlnXL2NrFSp5+G97VFtnbZ47seumsDlqplk+JvTJVGUaYKtZidsW WqaxM2FbyG74borzMG9OXaBsd9TRiLQZFPh5OwM0M/O2cC0aeJ2JkaDTL7dbnfzMZDN4EahckeIeh bt4GEjHzTODyL8twT1WLv+4zT2U9rh0/w9NLkwJyzXK4qkYY0mVpfE6Do6vp59T3/JrQy2h9LjIHM K0why4UTy48raKgjKebvrnGfuFNgduzjOMHrCmaI7W8riRW5+cIG+/Dnlbo+2fx2tJDiF6Q1KBCPg Wdjw1tqXJwD++vouyhgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pywCG-006BIS-12; Tue, 16 May 2023 15:02:40 +0000 Received: from mail-lj1-x22a.google.com ([2a00:1450:4864:20::22a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pywCC-006BH2-2s for linux-arm-kernel@lists.infradead.org; Tue, 16 May 2023 15:02:38 +0000 Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2ad89c7a84fso121853311fa.2 for ; Tue, 16 May 2023 08:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684249354; x=1686841354; 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=Ob8Y+0KV9XkYWxgRnvgVekYB7Mmh3+rr9E9J7Dt2yR0=; b=hXp0Usv2O4CmM52L1+L8EfhdpELI7Qo2pQwzaQsiPBqxRR6+QNnUlnUjXsVGBPEp0c aTB9nnE3dHvnPH7J7aPnVWpZ/BZEJEaps12KcVJuDjU+SZK+3Na+ffYP8zOY3dBHL+KW 0XboQYx3WWF/VTOGiKe1ytAJf4pqwdUfzyV5aD8FF+7V7gJBx1kw1R7CqpXpAmb0RP9V LIom0Ib4hzKuGuc/u/H7YpL/yI6uc+ULpgofW+5UGe1e+E1+KtEuEU5tyfFtEiVybN2c dBbbonXrmYp/bRoTPLq4o/s5w+JKbJ/Au0njsjqdmB1SfzkJxJHD37KiPx8czYPzY01/ MY9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684249354; x=1686841354; 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=Ob8Y+0KV9XkYWxgRnvgVekYB7Mmh3+rr9E9J7Dt2yR0=; b=lR6cQc1pJ6JJBRrZz0zW6gbnxGGdKanmjK00p9dmE5MisYHwlb3HITW53XGUkbu3FF LvvgTZw+DWJOzKHCfQykid6dm3EFUsbxOEqwPXPcPnxodjIG6/KwbPfIF4QAQIL4HEwb ec/FKfsN1q+KcvqorETyueDFFLay8EgqWEpTFbmXFSK4zT7xSsEHCtvYiz4qIZ7i56mO QJ8l55yXYBtQww4tm41hVx9CLkX0S5Y6JpThHmsjV3HEKpRdBzla7g8gwMgiiy9B4xQv FYVi9omovGY9kQ1GgkgRbik15dwpwHoi6/VI/7hqkOth+aoWTekFxAT3WQs+6O9mb7fQ 24uA== X-Gm-Message-State: AC+VfDziXnvWCCH7LzUMTCsVMkDE2IPkiyAF7baxLwnm2TvPsLwObkjA HGEtErt82uuG9uBigdN8lhU= X-Google-Smtp-Source: ACHHUZ6tlb1Ri3yIFk3olQAshLMgctaz8XK5rC2akWNevkqnBEdlTks3bcSva920lqxdAmnF7Ilorw== X-Received: by 2002:a2e:80ca:0:b0:2ac:53f7:41ea with SMTP id r10-20020a2e80ca000000b002ac53f741eamr8496758ljg.46.1684249353974; Tue, 16 May 2023 08:02:33 -0700 (PDT) Received: from pc636 (host-90-235-18-147.mobileonline.telia.com. [90.235.18.147]) by smtp.gmail.com with ESMTPSA id m24-20020a2e8718000000b002a8aa82654asm4058450lji.60.2023.05.16.08.01.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 08:02:02 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 16 May 2023 17:01:55 +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 Subject: Re: Excessive TLB flush ranges Message-ID: References: <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87o7mk733x.ffs@tglx> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230516_080237_109156_D3DB1193 X-CRM114-Status: GOOD ( 26.09 ) 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 04:38:58PM +0200, Thomas Gleixner wrote: > On Tue, May 16 2023 at 15:42, Uladzislau Rezki wrote: > >> _vm_unmap_aliases() collects dirty ranges from per cpu vmap_block_queue > >> (what ever that is) and hands a start..end range to > >> __purge_vmap_area_lazy(). > >> > >> As I pointed out already, this can also end up being an excessive range > >> because there is no guarantee that those individual collected ranges are > >> consecutive. Though I have no idea how to cure that right now. > >> > >> AFAICT this was done to spare flush IPIs, but the mm folks should be > >> able to explain that properly. > >> > > This is done to prevent generating IPIs. That is why the whole range is > > calculated once and a flush occurs only once for all lazily registered VAs. > > Sure, but you pretty much enforced flush_tlb_all() by doing that, which > is not even close to correct. > > This range calculation is only correct when the resulting coalesced > range is consecutive, but if the resulting coalesced range is huge with > large holes and only a few pages to flush, then it's actively wrong. > > The architecture has zero chance to decide whether it wants to flush > single entries or all in one go. > Id depends what is a corner case what is not. Usually all allocations are done sequentially. From the other hand it is not always true. A good example is a module loading/unloading(it has a special place in vmap space). In this scenario we are quite far in vmap space from for example VMALLOC_START point. So it will require a flush_tlb_all, yes. > > There is a world outside of x86, but even on x86 it's borderline silly > to take the whole TLB out when you can flush 3 TLB entries one by one > with exactly the same number of IPIs, i.e. _one_. No? > I meant if we invoke flush_tlb_kernel_range() on each VA's individual range: void flush_tlb_kernel_range(unsigned long start, unsigned long end) { if (tlb_ops_need_broadcast()) { struct tlb_args ta; ta.ta_start = start; ta.ta_end = end; on_each_cpu(ipi_flush_tlb_kernel_range, &ta, 1); } else local_flush_tlb_kernel_range(start, end); broadcast_tlb_a15_erratum(); } we should IPI and wait, no? -- Uladzislau Rezki _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel