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=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, 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 D9E89C4743C for ; Sat, 5 Jun 2021 02:53:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BFA2B613DE for ; Sat, 5 Jun 2021 02:53:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231570AbhFECzR (ORCPT ); Fri, 4 Jun 2021 22:55:17 -0400 Received: from mail-pg1-f169.google.com ([209.85.215.169]:37867 "EHLO mail-pg1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230169AbhFECzQ (ORCPT ); Fri, 4 Jun 2021 22:55:16 -0400 Received: by mail-pg1-f169.google.com with SMTP id t9so9327503pgn.4; Fri, 04 Jun 2021 19:53:29 -0700 (PDT) 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=JOIBq+kEIRNe1HY/dU/O4ueknvMC0Jdakk1cdBJSPGw=; b=bmjRiedlJqGYPmfoB1i8FSdNGJRe69WfRRrbZKLnzmCjCN6oYAc7C+cA6rGIaualIa l4qfmOQJIsm7mhy2xoCiiJH+FQPWEeFsp+EXdX5NbUH6NsMQaY+MlseKfd3Hvx4uOVGn UXRafGp2Fj88+KWaP6+yFK6VGS1/vyvOtdyFE0a+tsXogRE4WZXsTm1ULstUvITaipP4 epBUGZ2XXQp+BJ0jYpiTueNcZ4TaFVTYz7io/EVMlyKqefZueRmwrZW5ZOgK9kQvVamJ /MZu3JkZo3Q7ZQFVUbpZ+xH0misk9s54/+KbVu0/tQItvT6W0oLt0ZQJdJOPg0+V+cNY fYFw== 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=JOIBq+kEIRNe1HY/dU/O4ueknvMC0Jdakk1cdBJSPGw=; b=DZEOS0/9Afz8i8fqjnFVB2Z2id+sigeKBrLZPmBb+GnGUjVfSt8qxtQ2sKwFhcvcSC ArynL0t7TyYw1ohbLSwVwW/dhQ+LgRLff7Ojip6e/D86hO6R0Aruv/nmm13g67aXN9ts t6ppsiCIwO4LrfaMWxJzYdncsKl9hC5aFEBDyNuwUgrJV+6qnrVohWRnVDdIbCA2mlnr qCimqX6cbWJ+MpRlBLcSJ2Pf/RmQkdiZYa5Dg6t2aqi8nG5plPqlyJzI+zqhqXO/dclG GeEgHaRKeNlSslXopWvtw+9+3sS97Tib39fLHIOLj4a8pXdKgnY4zmgp35Eel+ZF0E7+ ooNQ== X-Gm-Message-State: AOAM531O5/S7l78mekJbs6N9IGJQSgELjKk0wdpHiP4moZCqMAApR9O0 8PhajBR0EB5GQwtd0k1r9aI= X-Google-Smtp-Source: ABdhPJxvqDGzb9ptMsdZWbbSUmPkKDSnpbG8bYthCJXvTG4JTcEDkvH65Y6fagb+39d85vOfUJU5mA== X-Received: by 2002:a62:7b4c:0:b029:2e9:cec2:e252 with SMTP id w73-20020a627b4c0000b02902e9cec2e252mr7446083pfc.56.1622861549693; Fri, 04 Jun 2021 19:52:29 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id iq15sm3337816pjb.53.2021.06.04.19.52.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 19:52:29 -0700 (PDT) Date: Sat, 05 Jun 2021 12:52:23 +1000 From: Nicholas Piggin Subject: Re: [PATCH v3 0/4] shoot lazy tlbs To: Andrew Morton , Andy Lutomirski Cc: Anton Blanchard , linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Randy Dunlap References: <20210601062303.3932513-1-npiggin@gmail.com> <603ffd67-3638-4c47-8067-c1bdfdf65f1b@kernel.org> <991660c3-c2bf-c303-a55c-7454f0cc45f7@kernel.org> <1622851909.wxi3vcx3m8.astroid@bobo.none> <1622852601.xyhcpcfd7y.astroid@bobo.none> In-Reply-To: <1622852601.xyhcpcfd7y.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1622861133.mb1njgfop9.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Excerpts from Nicholas Piggin's message of June 5, 2021 10:26 am: > Excerpts from Nicholas Piggin's message of June 5, 2021 10:17 am: >> Excerpts from Andy Lutomirski's message of June 5, 2021 3:05 am: >>> On 6/4/21 9:54 AM, Andy Lutomirski wrote: >>>> On 5/31/21 11:22 PM, Nicholas Piggin wrote: >>>>> There haven't been objections to the series since last posting, this >>>>> is just a rebase and tidies up a few comments minor patch rearranging= . >>>>> >>>>=20 >>>> I continue to object to having too many modes. I like my more generic >>>> improvements better. Let me try to find some time to email again. >>>>=20 >>>=20 >>> Specifically, this: >>>=20 >>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?= h=3Dx86/mm >>=20 >> That's worse than what powerpc does with the shoot lazies code so=20 >> we wouldn't use it anyway. >>=20 >> The fact is mm-cpumask and lazy mm is very architecture specific, so I=20 >> don't really see that another "mode" is such a problem, it's for the=20 >> most part "this is what powerpc does" -> "this is what powerpc does". >> The only mode in the context switch is just "take a ref on the lazy mm" >> or "don't take a ref". Surely that's not too onerous to add!? >>=20 >> Actually the bigger part of it is actually the no-lazy mmu mode which >> is not yet used, I thought it was a neat little demonstrator of how code >> works with/without lazy but I will get rid of that for submission. >=20 > I admit that does add a bit more churn than necessary maybe that was > the main objection. >=20 > Here is the entire kernel/sched/core.c change after that is removed. > Pretty simple now. I'll resubmit. If it gives you some concerns about a great complex new mode, I'll put it a different way -- all this allows is the arch to say that it does not use lazy tlb mms beyond their refcounted lifetime, so there is no need to refcount the lazy tlb reference. That's all it is. One implementation of that is shoot lazies, and that could be done entirely in arch/powerpc via destroy_context (I just put=20 it in mm/ in case it is useful to others, but that's no real=20 difference). So you see it's really just about management of lazies, the refcounting is just a bit on the side. And lazy management is highly arch specific, x86 being one of the really different complex ones there including very complex and unique interactions with membarrier ordering, so that can't be a fair objection. Thanks, Nick 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=-5.5 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,MENTIONS_GIT_HOSTING, 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 926A6C4743C for ; Sat, 5 Jun 2021 02:53:05 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 02142613DE for ; Sat, 5 Jun 2021 02:53:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 02142613DE 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 boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Fxkhb4rqfz30BG for ; Sat, 5 Jun 2021 12:53:03 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=bmjRiedl; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::530; helo=mail-pg1-x530.google.com; envelope-from=npiggin@gmail.com; receiver=) 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=bmjRiedl; dkim-atps=neutral Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 4Fxkh34M2nz2yxl for ; Sat, 5 Jun 2021 12:52:33 +1000 (AEST) Received: by mail-pg1-x530.google.com with SMTP id r1so9305421pgk.8 for ; Fri, 04 Jun 2021 19:52:32 -0700 (PDT) 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=JOIBq+kEIRNe1HY/dU/O4ueknvMC0Jdakk1cdBJSPGw=; b=bmjRiedlJqGYPmfoB1i8FSdNGJRe69WfRRrbZKLnzmCjCN6oYAc7C+cA6rGIaualIa l4qfmOQJIsm7mhy2xoCiiJH+FQPWEeFsp+EXdX5NbUH6NsMQaY+MlseKfd3Hvx4uOVGn UXRafGp2Fj88+KWaP6+yFK6VGS1/vyvOtdyFE0a+tsXogRE4WZXsTm1ULstUvITaipP4 epBUGZ2XXQp+BJ0jYpiTueNcZ4TaFVTYz7io/EVMlyKqefZueRmwrZW5ZOgK9kQvVamJ /MZu3JkZo3Q7ZQFVUbpZ+xH0misk9s54/+KbVu0/tQItvT6W0oLt0ZQJdJOPg0+V+cNY fYFw== 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=JOIBq+kEIRNe1HY/dU/O4ueknvMC0Jdakk1cdBJSPGw=; b=axBsihRlZy2o7mNB3LmR/+DQ32+m8rdcMj9v2iM0h3IRxqP+9KIYM0R9JP5o0hAW+y YoW/0S9hnw2SfpAogBuoRpvqMp0Il7Vnt+EG/3v+PgwD1k9zYAP22X8B8EW15YW1nbiU hQmc9/l2rpEJRlePNdasZIcjA3DZqyRqSHAzIEkQ46LETYN42C37q1dqLWG2yXT1lhM7 LOFKbfozwNQWEm0T+Y0y7dwgulTBNBgUKOQfGISD77J6YkWZ6mYQqISzUHKJPWdhUaYe IYBWownhwJCtNLzeLVay/X1CGv8kzopsscKrVXeF1g0qfVwmayWK7q97i81v+KvKipNw tJ/w== X-Gm-Message-State: AOAM531q9P4EPSnC7qEOmDIBhMzHthRWcRIjKgV7p8tTXAfq0iFqsRu9 UyE3JwqpQ7fL+EOyv+78nis= X-Google-Smtp-Source: ABdhPJxvqDGzb9ptMsdZWbbSUmPkKDSnpbG8bYthCJXvTG4JTcEDkvH65Y6fagb+39d85vOfUJU5mA== X-Received: by 2002:a62:7b4c:0:b029:2e9:cec2:e252 with SMTP id w73-20020a627b4c0000b02902e9cec2e252mr7446083pfc.56.1622861549693; Fri, 04 Jun 2021 19:52:29 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id iq15sm3337816pjb.53.2021.06.04.19.52.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 04 Jun 2021 19:52:29 -0700 (PDT) Date: Sat, 05 Jun 2021 12:52:23 +1000 From: Nicholas Piggin Subject: Re: [PATCH v3 0/4] shoot lazy tlbs To: Andrew Morton , Andy Lutomirski References: <20210601062303.3932513-1-npiggin@gmail.com> <603ffd67-3638-4c47-8067-c1bdfdf65f1b@kernel.org> <991660c3-c2bf-c303-a55c-7454f0cc45f7@kernel.org> <1622851909.wxi3vcx3m8.astroid@bobo.none> <1622852601.xyhcpcfd7y.astroid@bobo.none> In-Reply-To: <1622852601.xyhcpcfd7y.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1622861133.mb1njgfop9.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@vger.kernel.org, Randy Dunlap , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Excerpts from Nicholas Piggin's message of June 5, 2021 10:26 am: > Excerpts from Nicholas Piggin's message of June 5, 2021 10:17 am: >> Excerpts from Andy Lutomirski's message of June 5, 2021 3:05 am: >>> On 6/4/21 9:54 AM, Andy Lutomirski wrote: >>>> On 5/31/21 11:22 PM, Nicholas Piggin wrote: >>>>> There haven't been objections to the series since last posting, this >>>>> is just a rebase and tidies up a few comments minor patch rearranging= . >>>>> >>>>=20 >>>> I continue to object to having too many modes. I like my more generic >>>> improvements better. Let me try to find some time to email again. >>>>=20 >>>=20 >>> Specifically, this: >>>=20 >>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?= h=3Dx86/mm >>=20 >> That's worse than what powerpc does with the shoot lazies code so=20 >> we wouldn't use it anyway. >>=20 >> The fact is mm-cpumask and lazy mm is very architecture specific, so I=20 >> don't really see that another "mode" is such a problem, it's for the=20 >> most part "this is what powerpc does" -> "this is what powerpc does". >> The only mode in the context switch is just "take a ref on the lazy mm" >> or "don't take a ref". Surely that's not too onerous to add!? >>=20 >> Actually the bigger part of it is actually the no-lazy mmu mode which >> is not yet used, I thought it was a neat little demonstrator of how code >> works with/without lazy but I will get rid of that for submission. >=20 > I admit that does add a bit more churn than necessary maybe that was > the main objection. >=20 > Here is the entire kernel/sched/core.c change after that is removed. > Pretty simple now. I'll resubmit. If it gives you some concerns about a great complex new mode, I'll put it a different way -- all this allows is the arch to say that it does not use lazy tlb mms beyond their refcounted lifetime, so there is no need to refcount the lazy tlb reference. That's all it is. One implementation of that is shoot lazies, and that could be done entirely in arch/powerpc via destroy_context (I just put=20 it in mm/ in case it is useful to others, but that's no real=20 difference). So you see it's really just about management of lazies, the refcounting is just a bit on the side. And lazy management is highly arch specific, x86 being one of the really different complex ones there including very complex and unique interactions with membarrier ordering, so that can't be a fair objection. Thanks, Nick