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 45B61C433EF for ; Sun, 9 Jan 2022 04:38:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A51AB6B0072; Sat, 8 Jan 2022 23:38:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A00DD6B0073; Sat, 8 Jan 2022 23:38:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C8C76B0074; Sat, 8 Jan 2022 23:38:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0163.hostedemail.com [216.40.44.163]) by kanga.kvack.org (Postfix) with ESMTP id 7D4216B0072 for ; Sat, 8 Jan 2022 23:38:20 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 28C76818A601 for ; Sun, 9 Jan 2022 04:38:20 +0000 (UTC) X-FDA: 79009491960.27.0BE7CB9 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf13.hostedemail.com (Postfix) with ESMTP id CA7AB20011 for ; Sun, 9 Jan 2022 04:38:19 +0000 (UTC) Received: by mail-ed1-f53.google.com with SMTP id b13so39379765edd.8 for ; Sat, 08 Jan 2022 20:38:19 -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=cKLmBwFRChKjyGRlhA5QZ69vyjO3Rc64fIylW8FYkO8=; b=CqZjyqzn1xhOUvCPKeEnFZJ7UtJlgKL+16636LsOxfmx7vb5I7ijvSiwSYhJxJ0vQ7 tY5fUnpXVJfOS4jYOLQ0xhfhie0Q1pYNEpmbnzvsdCd3PNOu88aD0tW5eGe6uel/D+RR 3qxE6TDOHUCM3VuuUTsy4Sc4cIHAdBxQ4gyAw= 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=cKLmBwFRChKjyGRlhA5QZ69vyjO3Rc64fIylW8FYkO8=; b=KAyCXl9bexOlp9UA5Z3Ez/9aKltBStOdEEQj+4vjpC65jkZEvvCSRTRZUn1+Ofi2ze qNzIEfGgDriaxC3BbdvtkhoswuxRUoFQ72GFLCt54Ddq1fi+uA9JIBbiy/JAdqLoaRcs 4i3nqOLgZSWao8g37sDdsxXJ99/psEkOhjl/EvUcna33jNeZ3S2o2+LLyxS7Jgo18iON KGXnwu0MrIhT88o94E1rQcBCp8FT5uk/fzDyTCQWEuxARceasoYRyC0J+Lz5nwJpUoPw MdDOOK5fgzMm01LpWFG1GJ+3CURrdaYv9eezhBrfOhW08QFIu5L2aoPhIljuTpX3thHz MFXA== X-Gm-Message-State: AOAM530z0he7wA9uXWoxGnzbNdYo+ZHl22lrDy8ZSfAmianJr4kmg0P/ qGAsuhfPVMZRi6pr9x/x8N6laudcefoLh3ARFmA= X-Google-Smtp-Source: ABdhPJzxn0/T5dqSKSNY29srNH8mSqklOE7AIpwN4awxgK5OwYxQt8agLNKIiOfhsMnuWZBvpk9w+g== X-Received: by 2002:a17:906:e0d9:: with SMTP id gl25mr3930097ejb.44.1641703098459; Sat, 08 Jan 2022 20:38:18 -0800 (PST) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com. [209.85.221.53]) by smtp.gmail.com with ESMTPSA id g16sm1044208ejt.202.2022.01.08.20.38.18 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Jan 2022 20:38:18 -0800 (PST) Received: by mail-wr1-f53.google.com with SMTP id v6so19833154wra.8 for ; Sat, 08 Jan 2022 20:38:18 -0800 (PST) X-Received: by 2002:adf:f54e:: with SMTP id j14mr59075968wrp.442.1641703098055; Sat, 08 Jan 2022 20:38:18 -0800 (PST) MIME-Version: 1.0 References: <7c9c388c388df8e88bb5d14828053ac0cb11cf69.1641659630.git.luto@kernel.org> <3586aa63-2dd2-4569-b9b9-f51080962ff2@www.fastmail.com> <430e3db1-693f-4d46-bebf-0a953fe6c2fc@www.fastmail.com> In-Reply-To: <430e3db1-693f-4d46-bebf-0a953fe6c2fc@www.fastmail.com> From: Linus Torvalds Date: Sat, 8 Jan 2022 20:38:02 -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 Cc: Will Deacon , Catalin Marinas , 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: imf13.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=CqZjyqzn; spf=pass (imf13.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Queue-Id: CA7AB20011 X-Stat-Signature: 7uw5x6phq1i3bjqig6qb4p4j4pi81dzg X-Rspamd-Server: rspam04 X-HE-Tag: 1641703099-100341 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 Sat, Jan 8, 2022 at 7:59 PM Andy Lutomirski wrote: > > > 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. > > > > Well, I am an x86 mm maintainer, and there is definitely a performance problem on large x86 systems right now. :) Well, my point was that on x86, the complexities of the patch you posted are completely pointless. So on x86, you can just remove the mmgrab/mmdrop reference counts from the lazy mm use entirely, and voila, that performance problem is gone. We don't _need_ reference counting on x86 at all, if we just say that the rule is that a lazy mm is always associated with a honest-to-goodness live mm. So on x86 - and any platform with the IPI model - there is no need for hundreds of lines of complexity at all. THAT is my point. Your patch adds complexity that buys you ABSOLUTELY NOTHING. You then saying that the mmgrab/mmdrop is a performance problem is just trying to muddy the water. You can just remove it entirely. Now, I do agree that that depends on the whole "TLB IPI will get rid of any lazy mm users on other cpus". So I agree that if you have hardware TLB invalidation that then doesn't have that software component to it, you need something else. But my argument _then_ was that hardware TLB invalidation then needs the hardware ASID thing to be useful, and the ASID management code already effectively keeps track of "this ASID is used on other CPU's". And that's exactly the same kind of information that your patch basically added a separate percpu array for. So I think that even for that hardware TLB shootdown case, your patch only adds overhead. And it potentially adds a *LOT* of overhead, if you replace an atomic refcount with a "for_each_possible_cpu()" loop that has to do cmpxchg things too. Now, on x86, where we maintain that mm_cpumask, and as a result that overhead is much lower - but we maintain that mm_cpumask exactly *because* we do that IPI thing, so I don't think you can use that argument in favor of your patch. When we do the IPI thing, your patch is worthless overhead. See? Btw, you don't even need to really solve the arm64 TLB invalidate thing - we could make the rule be that we only do the mmgrab/mmput at all on platforms that don't do that IPI flush. I think that's basically exactly what Nick Piggin wanted to do on powerpc, no? But you hated that patch, for non-obvious reasons, and are now introducing this new patch that is clearly non-optimal on x86. So I think there's some intellectual dishonesty on your part here. Linus