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 348B2C677F1 for ; Thu, 19 Jan 2023 00:53:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38E206B0072; Wed, 18 Jan 2023 19:53:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 316EE6B0073; Wed, 18 Jan 2023 19:53:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1B74D6B0074; Wed, 18 Jan 2023 19:53:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 070016B0072 for ; Wed, 18 Jan 2023 19:53:18 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C89084096F for ; Thu, 19 Jan 2023 00:53:17 +0000 (UTC) X-FDA: 80369724834.21.1B2FD02 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf06.hostedemail.com (Postfix) with ESMTP id 14D1B180003 for ; Thu, 19 Jan 2023 00:53:15 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VxMM+n7Z; spf=pass (imf06.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=npiggin@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=1674089596; 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=O5OwSqaa3k71xkT8WUUyBE4GL1c8ehjEm+lG2U3+ww8=; b=j4XMaVkB8wR6MPcu4T3/AaXI+w9HEiGzhPTskFwWnIOaXOtAoZ/ONZPcDWCDfrfAUcGFNe K01LSdPjX5Hv60vrwUvNRA9zof1Znzymn2zljdU+rX/vzLuAu22MI7cXhDflM8WMhNFN1x YOkaAJsFqyXIeZFdp4eUMCjmF4cIC3o= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=VxMM+n7Z; spf=pass (imf06.hostedemail.com: domain of npiggin@gmail.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=npiggin@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674089596; a=rsa-sha256; cv=none; b=IMvGGiQ374AloWmOojgoA+ARseM9bm54ORbtCZT9cpdlqVQYJ4FO4S4dhwwbUf4yca+brI 2sLGPWiOsacRt5s769n7/OQ9/vtpT+y5dLIrYGEomGoEPqZjUPLh165SPWg051G3jjXXHV tUigbNW9eYMDLOIeLIqa4LGYEdZGMjY= Received: by mail-pj1-f51.google.com with SMTP id b10so828084pjo.1 for ; Wed, 18 Jan 2023 16:53:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=O5OwSqaa3k71xkT8WUUyBE4GL1c8ehjEm+lG2U3+ww8=; b=VxMM+n7ZQ7ySdPZJagy+lvodZf7Ei6K4cGhxVW6vhCAISwMhETO4P0zAg5TL04X9mG so7hd1FvWPuhpb3FnNogypnG+GUvTjMyf29uuxUgkEKMKiKhjWFKZgy7XM+7zlRGbnLM XW8EB337vH9O7EDDbXqKRjCsTOjUSBIJYzj9n3ydNn7NDvys/PCYZU4rv+3ZH8698zjJ gjaog8MASkt1QYEddmOc4pZ/1fHtFmV0/EHae6jjaC9Tlr2Juoi/5SjXD2FC4l1tgw5X xSssM+NTSqUR/rVW3gPshuPqCCXxtCjGCfmoxOxkxaKFRfl3litjPnUrhQfV2nwMz9q0 bytw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=O5OwSqaa3k71xkT8WUUyBE4GL1c8ehjEm+lG2U3+ww8=; b=TOjJkKKXh988/BCDvh8W23kfsVTvI2RXoFtYmUvdK4NnUSqsSm2gNZqLDN/NQ4E+PL vRPr3RuMTS/O6SkWVmEJRSETNLkTsTBK2rgXD2t0bamadLujGEU2g9SOtcNw7IW1tdPN iGZQ8KvqcNvSEr+8WZ1r+eZAhOhodSeraiDFxGL0jIqjxi9aEi8he4ldLBTNcef9JkIE zqpXGyW+cbra3oWBFLhzrWhLUm0KQQQMXNZPG8PxT3kEX8Uwf2K6dVefxE5vQOuwZdL0 3GmxhnHOAlhnFySAXiZDFuekm3mKBknlOEMa43TzVMpKVpBemFrj/lTuc0Xp6BWIZnuH 0DHA== X-Gm-Message-State: AFqh2koEiDwQsbS2rIbc9bDycsjwEqv9NWtzf8ytSC7NGPFRBBRvHkaA US1mP8JupukhX+18EV0MUEw= X-Google-Smtp-Source: AMrXdXsMSS9dcXgYVyvRoV4FT2tnzvT0wkiLbe+rSWN6jjYwj9dD2M9R08hcXMB91pi0HSAg9oFG6g== X-Received: by 2002:a17:90a:5a45:b0:229:2bbb:261f with SMTP id m5-20020a17090a5a4500b002292bbb261fmr9919226pji.8.1674089594735; Wed, 18 Jan 2023 16:53:14 -0800 (PST) Received: from localhost (193-116-102-45.tpgi.com.au. [193.116.102.45]) by smtp.gmail.com with ESMTPSA id o11-20020a17090a420b00b002296312adcesm1888963pjg.56.2023.01.18.16.53.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Jan 2023 16:53:13 -0800 (PST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 19 Jan 2023 10:53:08 +1000 Message-Id: Cc: "Andrew Morton" , "Andy Lutomirski" , "Linus Torvalds" , "linux-arch" , "linux-mm" , Subject: Re: [PATCH v6 3/5] lazy tlb: shoot lazies, non-refcounting lazy tlb mm reference handling scheme From: "Nicholas Piggin" To: "Nadav Amit" X-Mailer: aerc 0.13.0 References: <20230118080011.2258375-1-npiggin@gmail.com> <20230118080011.2258375-4-npiggin@gmail.com> <5F3590B8-3F25-4EFB-BE3A-D32AAAC0B2F4@gmail.com> In-Reply-To: <5F3590B8-3F25-4EFB-BE3A-D32AAAC0B2F4@gmail.com> X-Rspamd-Queue-Id: 14D1B180003 X-Stat-Signature: ng5yhio1bmz39x6kkyh9gm3hqxwiz638 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1674089595-133289 X-HE-Meta: U2FsdGVkX1+TqTnDIlH+r+L4SSpz7zO44z+mJPup+ynvlDhlzzIwM/4sXBhyTEywbY82aYq3qKsQELxeeAlrk9qBLUuRbu/ia4oVsNS9LgX/patoWXfRtHzyICDJPAtXCEgvYjuPOYzMOJbUD2JB1scEYSaq0ahrvGlYCTubaDhwFhH8Z+s2+VQ+1RETjRJgEgYCfvs+78qTGUXAtI5J+vEIrnmcgsVwJ8V2aRlQqG+4/kdsIORHqVwpKM7dJ8MgSntVI2vldLGfX3OMeSjGp0Xcc12fcedXovOSGozE4qDPMb2vWWWL3lh3OylXkWcT+SLk8qeQmmDGCMy2kntCfEPwIEl4gEFA0XT9dwipsG9t/CQ8K/ooL6j0QriDJH7vxatovrCd3fkpmA+SZPnFCpcGrq8EbGfSio1pmN5BSJhYS2lCYN6fLuk3Wbo4fVlXd+4vVVo3gf2bWnzgwTQ8ZA8Rmqu+rpnofDlGgrSMACaMap57QX24/0BcOzMJx7cKrCM39Sbk1YIN59ZkkNF+4l+uLzi2nfM5qICZtZcpvPPU5MljIgYpla17V6vusYDyuyIdskj6BugL01pBckYoIpvmAi3u/QzoEkC9USGb3JbBhI3+c3cthQTbt9uSeXiH+ZXyO6NUKtPnJldNoTY7MjOMPvbDrkGm4dsn2puMxRCnPScjSmBAwnSbOGAWPGVMk0JQRdbur3UzmazwkH9r0zRURV11dmNoXdx4HnPoNg758gXIQPBWnmj1z+cV3TF4R4jUEUGpKHB3xBV2QouaNsYH9Nx+Y61DdRps8I6FQBfEGAWOtFL8UYKuArxT4RxkdD+0QFVBCTaDrOZk0QPP3gRUIBvefnjltFmfdpiVBpTeyuFHSYvYzFLnmYYUMgIVkZpkY4K5fuV/0dNcmlPBUFUXOnlLkjKOmDCnDoLP7uLfZ4r/dq5p6c9wR2rJ7mGKkfD1EJEm4N2vjHoOrqi tRbIeLtP 9v37+uq0KgcI0hFIKF4/O9pNlRa6HU/DtRIVDDyB9a6neV0RgIeNNGT/zPOXGSaKqwHjaU3P4bTmkYkrlBng71aV0WjYZIdY5AN7B6e8okU3kqiGKa1Ainu4xbaCFc5WnuHzzqrVuLiqi0acu/ywxV7wohWvf0Uzp0hpmU5imtvsCZuy1Ua/rbup+xQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.016103, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu Jan 19, 2023 at 8:22 AM AEST, Nadav Amit wrote: > > > > On Jan 18, 2023, at 12:00 AM, Nicholas Piggin wrote= : > >=20 > > +static void do_shoot_lazy_tlb(void *arg) > > +{ > > + struct mm_struct *mm =3D arg; > > + > > + if (current->active_mm =3D=3D mm) { > > + WARN_ON_ONCE(current->mm); > > + current->active_mm =3D &init_mm; > > + switch_mm(mm, &init_mm, current); > > + } > > +} > > I might be out of touch - doesn=E2=80=99t a flush already take place when= we free > the page-tables, at least on common cases on x86? > > IIUC exit_mmap() would free page-tables, and whenever page-tables are > freed, on x86, we do shootdown regardless to whether the target CPU TLB s= tate > marks is_lazy. Then, flush_tlb_func() should call switch_mm_irqs_off() an= d > everything should be fine, no? > > [ I understand you care about powerpc, just wondering on the effect on x8= 6 ] If you can easily piggyback on IPI work you already do in exit_mmap then that's likely to be preferable. I don't know the details of x86 these days but there is some discussion about it in last year's thread, it sounded quite feasible. This is stil required at final __mmdrop() time because it's still possible that lazy mm refs will need to be cleaned. exit_mmap() itself explicitly creates one, so if the __mmdrop() runs on a different CPU, then there's one. kthreads using the mm could create others. If that part of it is unclear or under-commented, I can try improve it. Thanks, Nick