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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B133EC433FE for ; Fri, 4 Dec 2020 07:56:55 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9FC2622581 for ; Fri, 4 Dec 2020 07:56:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FC2622581 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4CnQ5b4XbVzDrQ5 for ; Fri, 4 Dec 2020 18:56:51 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::632; helo=mail-pl1-x632.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=D7BZBLvP; dkim-atps=neutral Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4CnQ3H67QdzDrMG for ; Fri, 4 Dec 2020 18:54:51 +1100 (AEDT) Received: by mail-pl1-x632.google.com with SMTP id s2so2656052plr.9 for ; Thu, 03 Dec 2020 23:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=Zd7vmIfn6mzRaP11y/d7gH60I8gBLNa0mgMkL/toHvQ=; b=D7BZBLvP7Hf1hmbzDKHSvvrVMOcvwF3AuA29oTyK7LjSZGu/VvtRnPQYcM5WAhLexX 7bxa66KLQ1nPLAHY7ASZKpcwj5k4Gj/sH6hD+9zfRuCPL4Lu5Awdy7z/+hdMDs8coD6V l8QYpI7vYdOmv55h5fB66u95Ohlgdwe0LaK+5MOxosaBfJT8hPUQpfvR3VXriGDatcPY gC/wXJZUtokL+ZYqMSshMZD74n/sJqggisoqq4cqL2SS5depbndddaDAtLka4PdXM3mG ge7JlJgFKZL1EYg7DD8hAPDTSPAXEGItK4mF9rjhF/tHePvbjm4v2usCJOMPjNtlHjbc kstQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=Zd7vmIfn6mzRaP11y/d7gH60I8gBLNa0mgMkL/toHvQ=; b=Rzl0Q3VKnI+9dm8EOWIwq4nxjEZxqfMrI72R0NQIFpkpOmY1LMRKThLmRCjvYFdNAg /FX1/oxB8iTr5xjrx0hMvODtgs/AyZcIAvcItNO8/6aGMRhs4nSj3NofIx4ar0PGx6Il L6c7qYPqAE2Y8fI4NHcG/NfvrUSf4CUH3r3ha4616L6SWayWde+8nU6v8wloOSJa6S6e UdMG0UoR6a+DMslZZ74Msjpr+2/aqhNCpKRBnlnBLJsXLXPblEhyWiz2qwa50i6qPrIx NYyuew6MuJeg0YxFAzjTpBH6w8OiF+oIlgKb25QvZ7FwH2W+VJo1FPgwdQtP1NnK4NVW 8Lcw== X-Gm-Message-State: AOAM532iradI56xhjQFGSxcR7PxYYHRRkYOTibCVRpIDuFHAcjBQG1F+ NXGbAyujmRRJEy/Sd4CAZv8= X-Google-Smtp-Source: ABdhPJxeaLakUaj4UZ6Mhmu/RUCo9vMWAs3X7UoKC0s3gdL5d5oy/Bq+kELLNyqZeAnUbZAiHbipyw== X-Received: by 2002:a17:902:a388:b029:da:bad:ed3 with SMTP id x8-20020a170902a388b02900da0bad0ed3mr2711686pla.76.1607068487823; Thu, 03 Dec 2020 23:54:47 -0800 (PST) Received: from localhost ([1.129.136.201]) by smtp.gmail.com with ESMTPSA id f15sm1346786pju.49.2020.12.03.23.54.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Dec 2020 23:54:47 -0800 (PST) Date: Fri, 04 Dec 2020 17:54:40 +1000 From: Nicholas Piggin Subject: Re: [RFC v2 2/2] [MOCKUP] sched/mm: Lightweight lazy mm refcounting To: Andy Lutomirski References: In-Reply-To: MIME-Version: 1.0 Message-Id: <1607065599.ecww2w3xq3.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch , Nadav Amit , X86 ML , Arnd Bergmann , Jann Horn , Catalin Marinas , Rik van Riel , LKML , Linux-MM , Dave Hansen , Will Deacon , Mathieu Desnoyers , linuxppc-dev Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Excerpts from Andy Lutomirski's message of December 4, 2020 3:26 pm: > This is a mockup. It's designed to illustrate the algorithm and how the > code might be structured. There are several things blatantly wrong with > it: >=20 > The coding stype is not up to kernel standards. I have prototypes in the > wrong places and other hacks. >=20 > There's a problem with mm_cpumask() not being reliable. Interesting, this might be a way to reduce those IPIs with fairly=20 minimal fast path cost. Would be interesting to see how much performance=20 advantage it has over my dumb simple shoot-lazies. For powerpc I don't think we'd be inclined to go that way, so don't feel=20 the need to add this complexity for us alone -- we'd be more inclined to=20 move the exit lazy to the final TLB shootdown path, which we're slowly=20 getting more infrastructure in place to do. (The powerpc hash MMU code which we're slowly moving away from might=20 never get that capability because it's complex there and hard to do with that virtualisation model so current big systems (and radix MMU until we finish the TLB flushing stuff) want something here, but for those the shoot-lazies could quite likely be sufficient) But if core code was moved over to something like this for the benefit of others archs we'd probably just as happily do that. There's a few nits but I don't think I can see a fundamental problem=20 yet. Thanks, Nick