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 6F750C7EE22 for ; Wed, 17 May 2023 22:42:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F29DD900005; Wed, 17 May 2023 18:42:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDA0D900003; Wed, 17 May 2023 18:42:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DA12B900005; Wed, 17 May 2023 18:42:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C47A9900003 for ; Wed, 17 May 2023 18:42:07 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9B5394071D for ; Wed, 17 May 2023 22:42:07 +0000 (UTC) X-FDA: 80801221494.17.6241C52 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by imf07.hostedemail.com (Postfix) with ESMTP id B10334000F for ; Wed, 17 May 2023 22:42:05 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=PPzV7SAI; spf=pass (imf07.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=nadav.amit@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=1684363325; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=41fW4BpmZ1DIPSrMuQbfRBLRaLCvPdPUALCXusnHZ2o=; b=T8WSBVC4wuvSVKU9Kod0uk/iipXUfT8IvQ96ucndoBM9KwuLuAn8GtcunkAyQSBCDhTuoc 6NxoU2WZYB+CvPtJf0kc/8tfwdjzM8sBey1wO147HcDjEW9mW1Q9L/sLC6iOe0keN50uRy IlePB9GfkKI07Xuig3IzluOg//q2uso= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684363325; a=rsa-sha256; cv=none; b=LlRn9Y/JurzRdEQ63LCHq4dvW0lmUh82fOhHkl0JRSzMFO6NbRKLb4AyQnXb+PrlNd3mK1 sNnWKLuJHNNjam2AUgGisIpihoXlV0Vmo+KtIPxxDBkEqNl0jZyC1weZ5f4pfz+dWmvWYi R2T3YDh62F/M5hRrftvMMxxeiKw551c= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=PPzV7SAI; spf=pass (imf07.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.172 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-64390dc0a7fso428463b3a.1 for ; Wed, 17 May 2023 15:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684363324; x=1686955324; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=41fW4BpmZ1DIPSrMuQbfRBLRaLCvPdPUALCXusnHZ2o=; b=PPzV7SAId/72SF3Xwmj2d4TQFq1mpZYBQ8CQJhK/rd/xErZcx8ignt5ERjksIDjy5u INzi7FPxIduLNarx9vKafwU6BIm+7ME0TAE5jReUzoHKquZ3IRJeBnI9YSzmlDP1hc4M FvMl8vpbiBkbms9v6MAzyLyjr1b0FyujTMi3FZfmM/pwZsOItwn3cqMqbL4S+q68tkEW aCjjSFT15KNsaljpqfkBEp4jt9O3qOOfu2+SSZAHxUgBBUSvhzkdoSYG067xKf8GN2/Q qLollJmrh7gMxKeNeGkgrTk/He2PT/vB3616o0b96GFk8wpjF9Wa/ILxK6AaphM+y4x5 w6ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684363324; x=1686955324; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=41fW4BpmZ1DIPSrMuQbfRBLRaLCvPdPUALCXusnHZ2o=; b=P72vN1rszzkgLJnXt+4XOcPxtfNMKHNkZVH38o4Y+hZGgvDZvKeDMKbXkYoV1kZ/JW RJgvJClWI7Ys3IgevZ5v/okstfxduw/XJ/w1dVIyWPyUMq2JvBNADunWQ8yzb4sBnM6i bz+alj18yuVIDLebNCEU+pnsUcvXf2lCfl2tflScBVFeNdufgV3uXfmCf0NVcQccUVfZ 1rmMiT7+AV1qILAzkVN9NT1MWLfBb3tPTE2+qXki0i2zsuSxhz5MbgYHog3YP5W1IyoE ngen+nSlGNh6Km8wGd5p1vS6ZTlX+Zzm2hnUJ+LEphqu49urcgRGPdmhlR4alOSjY2c4 l+KA== X-Gm-Message-State: AC+VfDy+Rgd7eAkMN7J6vqywuOPHodFVmFW05gCkQHupvKuw7bmm8Ao/ pkCSnQsqcEm551GJlZBcaYY= X-Google-Smtp-Source: ACHHUZ5kulD0aEdkNc72/z6OILLvuFtbX2bXadHP1RH3OJdHcsST1MCc+eXgsaunwsQrFpLw1wwQCA== X-Received: by 2002:a05:6a00:2d8f:b0:63d:6744:8cae with SMTP id fb15-20020a056a002d8f00b0063d67448caemr1061341pfb.2.1684363324100; Wed, 17 May 2023 15:42:04 -0700 (PDT) Received: from smtpclient.apple ([66.170.99.95]) by smtp.gmail.com with ESMTPSA id a18-20020a62bd12000000b0063d24fcc2besm31126pff.125.2023.05.17.15.42.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 May 2023 15:42:03 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: Excessive TLB flush ranges From: Nadav Amit In-Reply-To: <87r0rf5ge3.ffs@tglx> Date: Wed, 17 May 2023 15:41:51 -0700 Cc: Uladzislau Rezki , "Russell King (Oracle)" , Andrew Morton , linux-mm , Christoph Hellwig , Lorenzo Stoakes , Peter Zijlstra , Baoquan He , John Ogness , linux-arm-kernel@lists.infradead.org, Mark Rutland , Marc Zyngier , x86@kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <772904E1-4D6C-4D94-A24E-84325C11656D@gmail.com> References: <87a5y5a6kj.ffs@tglx> <87353x9y3l.ffs@tglx> <87zg658fla.ffs@tglx> <87r0rg93z5.ffs@tglx> <87cz308y3s.ffs@tglx> <87y1lo7a0z.ffs@tglx> <87o7mk733x.ffs@tglx> <7ED917BC-420F-47D4-8956-8984205A75F0@gmail.com> <87bkik6pin.ffs@tglx> <87353v7qms.ffs@tglx> <87ttwb5jx3.ffs@tglx> <87r0rf5ge3.ffs@tglx> To: Thomas Gleixner X-Mailer: Apple Mail (2.3731.500.231) X-Stat-Signature: 67hchukoeiop1d1jwxesp6x1cpcjtrgf X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: B10334000F X-HE-Tag: 1684363325-295303 X-HE-Meta: U2FsdGVkX19c9m/7OZm3znKxmNZtJCP5kFgoQ353WB1zXm/eJvQyT5LKioyh2357lRaLEWzf/5kzyUn7ExGMRUz0IrZrVv8eJdSVXeTk38AZXSQNkGis7QMu/O2DNKw3/3FDfcl+MyuprB9N/gHJzu6SRZKxXQCbxA60uRXgMPAiOVQ3ggD+Jx4PrrFd0heiqPdTcLq2AsIOm9bHFq86MOnelRsN/jMTH52gqEaEklW7FfxvM+kxnxHfVkvYN4Zcf8MkrEuJ4u0aeMWeul5ZMeWCZOeDZ9mkN3R+mBIBsbrzCaqOx08vbeCZnRoqZMakCDMzCng0BmqBANcLu9s/A72pNub5+Xx7dF6eVWJO1H9Do//o9QJqTeC8XoclcBxvAH3QaXr16aV9tT3pJpIehpE3qxGS4+jVuQgOFFiyyh44gLEi9AIpuJ48Mtxpk6q0NDy82kU7nGsDLyK//jHdvl0pZJMJDnOhDqWIsyJj9QsrhhBzS32IBXwle/IvNnfiQ5L0GAvUiTS1+1d7i0bNuu9wkaUzVpw02S/xNAUPmlZX/+kkPyiUI9WxNNFkCz8GWdGykIt5XlaUuPrRnCz8tkPg0eILD3/WLjuE3ytFpuROww1uYndwRxk6UlPF5Hf6uSQQjUGU34XTQW5aQekR1+fCzIUC3Pktb8/AnFXUJyP7EjsdbUnVP7XL43gT8UvbRoQtotRr1ShaW7CG5D1MuJIwEO0ELyStvaOtORoUmap8Go/r00sB0X10VGALARIB03SyQCJaBa0IbJvv4kzcYyHAK1KMgD0iyUQ9M4fMiQnft2xbbeVI8iKQ3cjZJj9sTj2pvluCy4H2BorEjgtgkFc5ARyzdBdihFNZiR4px/29uZFYUcEJFCYhICPmeSWSY7RLvX0I+Lnq+cbmxZaHzsZ7V/K+bi3aXgGN7ELoNOMyzkc3D0k8YlDyIZjiP7EUCM+Tgim5dgKn45N+6cm jebNDbGT 9zlHAGwQz3RnxAZms/wlVpjeU4QAYCqZRVqYuLVm7pOa7ZIBelikQgQgtHnDurlKtbfIiqd6Dsx2DcOE6PtRQkl0YMYZ1kjUcvHGevdbdmVpn7fu3LtHm/8ja0AEufxDbu117Whq8PGzAvdmxVbeG2UQ+5+lUCvDz4MZjF4tgJ5Vps3LyX6ead9NTZ2Q0mG/pTE2M60I245BG89Wk0i/qBStwvK8RqukBLLE0JbuHAUoWKZpe2lAMI4lLRGMhQDg1aYLgzw4KRx/EDSfEbOIdsmjw4GOt5oN0H/2BnLe45JZNySeVSUZ4XFIB/t019vFd57Q08xnWuBcIN017tXRwNqf7sxXhB+ByXsiXaNSWG6yNXP78qtif/lBqDIP1r5fN75+XOq8dswc1Oo93Vew5iS07EDoudsjomgS4jXjgYDoQuCBAzI0WZyIsX6GPWppX9TvcWuh+90F1xXZRrREuGHaI24ruZo8al7K5HFIr8piudF8= 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 May 17, 2023, at 4:47 AM, Thomas Gleixner = wrote: >=20 > On Wed, May 17 2023 at 12:31, Thomas Gleixner wrote: >> On Tue, May 16 2023 at 18:23, Nadav Amit wrote: >>>> INVLPG is not serializing so the CPU can pull in the next required = cache >>>> line(s) on the VA list during that. >>>=20 >>> Indeed, but ChatGPT says (yes, I see you making fun of me already): >>> =E2=80=9Chowever, this doesn't mean INVLPG has no impact on the = pipeline. INVLPG >>> can cause a pipeline stall because the TLB entry invalidation must = be >>> completed before subsequent instructions that might rely on the TLB = can >>> be executed correctly.=E2=80=9D >>>=20 >>> So I am not sure that your claim is exactly correct. >>=20 >> Key is a subsequent instruction which might depend on the to be = flushed >> TLB entry. That's obvious, but I'm having a hard time to construct = that >> dependent intruction in this case. >=20 > But obviously a full TLB flush _is_ guaranteed to stall the pipeline, > right? Right. I had a discussion about it with ChatGPT but it started to say = BS, so here is my understanding of the matter. IIUC, when you flush a TLB entry the CPU might have a problem figuring = out the translation of which memory addresses is affected. All the RAW = conflict detection mechanisms in such a case are probably useless, since even the granularity of the invalidation (e.g., 4KB/2MB/1GB) might be unknown = during decoding. It is not that it is impossible to obtain this information, it = is just that I am doubtful the CPU architects optimized this flow. As a result I think the pieces of code as the following ones are = affected (taken from from flush_tlb_func() ): while (addr < f->end) { flush_tlb_one_user(addr); addr +=3D 1UL << f->stride_shift; } flush_tlb_one_user has a memory clobber on the INVLPG. As a result = f->end and f->stride_shift would need to be reread from memory and their = loading would be stalled. As they reside in L1 cache already, the impact is low. Having said that, the fact that flush_tlb_one_user() flushes the =E2=80=9CPTI=E2=80=9D = (userspace mappings) as well does introduce small overhead relatively to the alternative of having two separate loops to flush kernel/userspace mappings when PTI is enabled. Long story short, I think that prefetching the entries that you want to flush - assuming they do not fit on a single cacheline - might be = needed. Linked list would therefore not be very friendly for something like = that. =20=