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 63416C433F5 for ; Sun, 9 Jan 2022 00:54:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEC3A6B0071; Sat, 8 Jan 2022 19:54:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B74C96B0073; Sat, 8 Jan 2022 19:54:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EE3F6B0074; Sat, 8 Jan 2022 19:54:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0180.hostedemail.com [216.40.44.180]) by kanga.kvack.org (Postfix) with ESMTP id 8A6956B0071 for ; Sat, 8 Jan 2022 19:54:16 -0500 (EST) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 4770898C11 for ; Sun, 9 Jan 2022 00:54:16 +0000 (UTC) X-FDA: 79008927312.05.1A07460 Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) by imf02.hostedemail.com (Postfix) with ESMTP id D366B80005 for ; Sun, 9 Jan 2022 00:54:15 +0000 (UTC) Received: by mail-ed1-f43.google.com with SMTP id c71so26463592edf.6 for ; Sat, 08 Jan 2022 16:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7zvEReNqkRUab5oYVSCs8wCUfMO8Yz5KCIMf8aOgdYE=; b=Rg+rcaglrF5BH+4vIFj86wzuPDqhPlDaexMTbCHoG8FJxYBbN+tipmYPYem0Tt6TNx /Dc6Y+yqZeqYco4OeqBvGl5nn3ivrV6mJhm/JLRlbOCuviFQuyc4rbKMTxTfP86nO2sS I5Pj+MPFjhGNYYQHir2wSYb9FgoaqQxZKVsO4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7zvEReNqkRUab5oYVSCs8wCUfMO8Yz5KCIMf8aOgdYE=; b=q95JePNUj3Pn4mudCs5SEEruZtgJnBONsJzSeGFmHW1lf2+DrAMKYSVn/JtnCYJDk9 h+PPxm+lNOvvIgBENawc0V6UuQU59G6o5o/lmLq3GSumynKVWDeAlJpkBuRT0XdxG+74 +8qt9Jg+qgEzqz8ZZ13YfcfjUs7FPRQKrh00xNEIv/V9oxQ7L4A7ZyrHH9yXQRHJb0NK ACibfI6ZHpMWC6nPMJeZJjulylN67zC3KjT4BE46C/GLTABxWPM6/XxCoEwRUJDjPfzG weHKfqk1lPEKL4EnmBCuErM29v0JURu8GACR+AwNaHrETuY4h3LcH1fxFM3XB0FBhpbK KAgA== X-Gm-Message-State: AOAM531yHhsHJsyxLbalX0yhktbmO1H6sBi0P7l0E3BnlDqlIXIkOZNy zvoVIhBRppLPFKV1/s0aPaELec74McYBHG815+g= X-Google-Smtp-Source: ABdhPJzn71BQw7jENefUap6Fm5a210PZEg2DKN+YLH6K03v5jXy54Mo6tuCW0WLb2Fa+gVrxY0pp7w== X-Received: by 2002:a17:907:6e89:: with SMTP id sh9mr53966857ejc.53.1641689654096; Sat, 08 Jan 2022 16:54:14 -0800 (PST) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com. [209.85.221.54]) by smtp.gmail.com with ESMTPSA id o25sm1379199edr.20.2022.01.08.16.54.13 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Jan 2022 16:54:13 -0800 (PST) Received: by mail-wr1-f54.google.com with SMTP id l25so8311458wrb.13 for ; Sat, 08 Jan 2022 16:54:13 -0800 (PST) X-Received: by 2002:adf:c74e:: with SMTP id b14mr26112698wrh.97.1641689653198; Sat, 08 Jan 2022 16:54:13 -0800 (PST) MIME-Version: 1.0 References: <7c9c388c388df8e88bb5d14828053ac0cb11cf69.1641659630.git.luto@kernel.org> <3586aa63-2dd2-4569-b9b9-f51080962ff2@www.fastmail.com> In-Reply-To: <3586aa63-2dd2-4569-b9b9-f51080962ff2@www.fastmail.com> From: Linus Torvalds Date: Sat, 8 Jan 2022 16:53:57 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 16/23] sched: Use lightweight hazard pointers to grab lazy mms To: Andy Lutomirski , Will Deacon , Catalin Marinas Cc: Andrew Morton , Linux-MM , Nicholas Piggin , Anton Blanchard , Benjamin Herrenschmidt , Paul Mackerras , Randy Dunlap , linux-arch , "the arch/x86 maintainers" , Rik van Riel , Dave Hansen , "Peter Zijlstra (Intel)" , Nadav Amit , Mathieu Desnoyers Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=Rg+rcagl; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.43 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D366B80005 X-Stat-Signature: 5ic8a85xdegaionzto93am3erzistr8b X-HE-Tag: 1641689655-120592 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: [ Let's try this again, without the html crud this time. Apologies to the people who see this reply twice ] On Sat, Jan 8, 2022 at 2:04 PM Andy Lutomirski wrote: > > So this requires that all architectures actually walk all relevant > CPUs to see if an IPI is needed and send that IPI. On architectures > that actually need an IPI anyway (x86 bare metal, powerpc (I think) > and others, fine. But on architectures with a broadcast-to-all-CPUs > flush (ARM64 IIUC), then the extra IPI will be much much slower than a > simple load-acquire in a loop. ... hmm. How about a hybrid scheme? (a) architectures that already require that IPI anyway for TLB invalidation (ie x86, but others too), just make the rule be that the TLB flush by exit_mmap() get rid of any lazy TLB mm references. Which they already do. (b) architectures like arm64 that do hw-assisted TLB shootdown will have an ASID allocator model, and what you do is to use that to either (b') increment/decrement the mm_count at mm ASID allocation/freeing time (b'') use the existing ASID tracking data to find the CPU's that have that ASID (c) can you really imagine hardware TLB shootdown without ASID allocation? That doesn't seem to make sense. But if it exists, maybe that kind of crazy case would do the percpu array walking. (Honesty in advertising: I don't know the arm64 ASID code - I used to know the old alpha version I wrote in a previous lifetime - but afaik any ASID allocator has to be able to track CPU's that have a particular ASID in use and be able to invalidate it). Hmm. The x86 maintainers are on this thread, but they aren't even the problem. Adding Catalin and Will to this, I think they should know if/how this would fit with the arm64 ASID allocator. Will/Catalin, background here: https://lore.kernel.org/all/CAHk-=wj4LZaFB5HjZmzf7xLFSCcQri-WWqOEJHwQg0QmPRSdQA@mail.gmail.com/ for my objection to that special "keep non-refcounted magic per-cpu pointer to lazy tlb mm". Linus