Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1219338imm; Wed, 22 Aug 2018 22:22:03 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyBEOFwHb4xgXRcBSIk5NjlG9R8+8mj7jdqJvKHf1RsnqPeuSxj39KY4ThDUf98oaUPtyUF X-Received: by 2002:a62:cf82:: with SMTP id b124-v6mr61160407pfg.142.1535001723174; Wed, 22 Aug 2018 22:22:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535001723; cv=none; d=google.com; s=arc-20160816; b=MMtSEDHNVrb89OUQAkPrtGvAkSpkWeGrHL6Y9gOGtkdp9kDB1oejpJeeEISuBKyUol gK8Jql3jA19y2Ay5gvUpq2IEoHCoEFk2qBpNTRGP5kshHJC05C4ScgkFPymYd/47oasd jJyckEqqM6sIdhb4hUaY/a4Tfx5X0btZ3laCmUbwvsorXpZ0fZVgJ4Hby7C46dhjdwlt mz7mp0E6bKwjw7Yv9Ei5QeC2mfoBrzMtGfkTvYustX0WnA8gMhtAHn3n09j23A/d0HCt DJW0TZ2i7bUBX9CwoQnLQtMgwfcjng3rwoCcFO++KLSScSAUVaQrYmhf+4DpJKjW7582 rdhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=VfYhSkuzLbWvGN5Yyw1bLznovxQO0cJsIYptolkzM78=; b=X0NIYgNuf/jxf5KV/lzXDMahYCwwR7D7CJgY35+jS3ZYS6+Np4gQeG1+YiFrNb7iS7 bDt1BtLFnpkmGEl+MIr4u3CPL1t7as6bVqj2a7fHUMX/kNOiuM50+g6fKescOHsAEQ4I dzpari7xY85Gn+Ugs+SNcvRtWCDk2V4IrVQTE4Yvqhnprhh5bqPZYbazfH/27iEI/IGb QfUzCLuxm+QxRH1sb4NTQ2DXJjmGK4oCnGa5qDN4VLPFe2q0cdYefn9r3DHhutnWsnoT AbVSCEI3AaJDhtma8yhR5gy8pybypJjusBNiSImSRXP7wc0nElp0uMWsmGjCHdzzKnnc +ZjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=SprMOk+g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 7-v6si3455386pgr.438.2018.08.22.22.21.47; Wed, 22 Aug 2018 22:22:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=SprMOk+g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728459AbeHWIsi (ORCPT + 99 others); Thu, 23 Aug 2018 04:48:38 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:45478 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728144AbeHWIsi (ORCPT ); Thu, 23 Aug 2018 04:48:38 -0400 Received: by mail-io0-f194.google.com with SMTP id e12-v6so3328723iok.12 for ; Wed, 22 Aug 2018 22:20:44 -0700 (PDT) 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=VfYhSkuzLbWvGN5Yyw1bLznovxQO0cJsIYptolkzM78=; b=SprMOk+g0dYyZm3f1Mmb9qnwHAVxXKp3c3CukIsxP0KFrHhmCiXpR0hzTw4Xev4an5 jE1fDYchWY88I7G145LH7ntg/9zC7m7t/tRDRYkhKWAWcnZcYfCgVshlqQ57kWbjzrLX 7tzWwFJqOLO6B3ks9BIcYEA5e0DSXByB+oKvc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VfYhSkuzLbWvGN5Yyw1bLznovxQO0cJsIYptolkzM78=; b=V/HUbCKI/w7QdHl+boen9Y4vqDHnNjvpl9x3byx6GqLiG1dmDz01g2idiDEFQ0qyAT EYJRlpCWAsdSbalIkkIaTrcDxNRV3tvmGcn+ZaxnwMpopiqbINSo8aVwkGdiWc3GjYM2 q8JxLLGCkZ5yhcdbFTDq6Flf9IBFVhXGv4M4hy4BxpDI3i71Kayd5jzld8Y5kLFPZIWP k+i1ZWSvVotzra9+L6+OiFz7DxQ1CA+SOjlnfqxqwCzfLcqMXG0UlZOfhzUFjvyQJwlP c9lfrdjzQ5WdTfsaVzhEWizzLksYErBl64NUPjyHrDja8tIg98T62Iw3L5bXqhr5HEHd Zkhg== X-Gm-Message-State: APzg51D0COLVFjVAE8ThaH8sxpRgqcaUQHW22fiAzqFo/cpqYdJq4i9/ ObPaSVnXdLL7Nw7MdKCYwmOMLtfrFODmn2sRri4= X-Received: by 2002:a6b:7a49:: with SMTP id k9-v6mr7078635iop.238.1535001643850; Wed, 22 Aug 2018 22:20:43 -0700 (PDT) MIME-Version: 1.0 References: <20180822153012.173508681@infradead.org> <20180822154046.823850812@infradead.org> <20180822155527.GF24124@hirez.programming.kicks-ass.net> <20180823134525.5f12b0d3@roar.ozlabs.ibm.com> <776104d4c8e4fc680004d69e3a4c2594b638b6d1.camel@au1.ibm.com> In-Reply-To: From: Linus Torvalds Date: Wed, 22 Aug 2018 22:20:32 -0700 Message-ID: Subject: Re: [PATCH 3/4] mm/tlb, x86/mm: Support invalidating TLB caches for RCU_TABLE_FREE To: Benjamin Herrenschmidt Cc: Nick Piggin , Peter Zijlstra , Andrew Lutomirski , "the arch/x86 maintainers" , Borislav Petkov , Will Deacon , Rik van Riel , Jann Horn , Adin Scannell , Dave Hansen , Linux Kernel Mailing List , linux-mm , David Miller , Martin Schwidefsky , Michael Ellerman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 22, 2018 at 10:11 PM Linus Torvalds wrote: > > So instead, when you get to the actual "tlb_flush(tlb)", you do > exactly that - flush the tlb. And the mmu_gather structure shows you > how much you need to flush. If you see that "freed_tables" is set, > then you know that you need to also do the special instruction to > flush the inner level caches. The range continues to show the page > range. Note that this obviously works fine for a hashed table model too - you just ignore the "freed_tables" bit entirely and continue to do whatever you always did. And we can ignore it on x86 too, because we just see the range, and we invalidate the range, and that will always invalidate the mid-level caching too. So the new bit is literally for arm and powerpc-radix (and maybe s390), but we want to make the actual VM interface truly generic and not have one set of code with five different behaviors (which we _currently_ kind of have with the whole in addition to all the HAVE_RCU_TABLE_FREE etc config options that modify how the code works. It would be good to also cut down on the millions of functions that each architecture can override, because Christ, it got very confusing at times to follow just how the code flowed from generic code to architecture-specific macros back to generic code and then arch-specific inline helper functions. It's a maze of underscores and "page" vs "table", and "flush" vs "remove" etc. But that "it would be good to really make everybody to use as much of the generic code as possible" and everybody have the same pattern, that's a future thing. But the whole "let's just add that "freed_tables" thing would be part of trying to get people to use the same overall pattern, even if some architectures might not care about that detail. Linus