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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 1DC2DC32792 for ; Mon, 30 Sep 2019 17:59:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE653224ED for ; Mon, 30 Sep 2019 17:59:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nvidia.com header.i=@nvidia.com header.b="SmdwlCKj" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE653224ED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=nvidia.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 722CB6B0006; Mon, 30 Sep 2019 13:59:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D3AF6B0007; Mon, 30 Sep 2019 13:59:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C1696B0008; Mon, 30 Sep 2019 13:59:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0225.hostedemail.com [216.40.44.225]) by kanga.kvack.org (Postfix) with ESMTP id 3550F6B0006 for ; Mon, 30 Sep 2019 13:59:33 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id CD4E475BC for ; Mon, 30 Sep 2019 17:59:32 +0000 (UTC) X-FDA: 75992349384.07.boys10_3627dd7e7ea3f X-HE-Tag: boys10_3627dd7e7ea3f X-Filterd-Recvd-Size: 5412 Received: from hqemgate15.nvidia.com (hqemgate15.nvidia.com [216.228.121.64]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Mon, 30 Sep 2019 17:59:31 +0000 (UTC) Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate15.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Mon, 30 Sep 2019 10:59:35 -0700 Received: from hqmail.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Mon, 30 Sep 2019 10:59:27 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Mon, 30 Sep 2019 10:59:27 -0700 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL105.nvidia.com (172.20.187.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 17:59:27 +0000 Received: from [10.2.173.141] (10.124.1.5) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 17:59:26 +0000 Subject: Re: [PATCH v4 01/11] powerpc/mm: Adds counting method to monitor lockless pgtable walks To: Leonardo Bras , , , , , CC: Keith Busch , Thomas Gleixner , Arnd Bergmann , Greg Kroah-Hartman , YueHaibing , "Nicholas Piggin" , Mike Rapoport , "Mahesh Salgaonkar" , Jason Gunthorpe , "Paul Mackerras" , Aneesh Kumar K.V , Ganesh Goudar , Andrew Morton , Ira Weiny , Dan Williams , Allison Randal References: <20190927234008.11513-1-leonardo@linux.ibm.com> <20190927234008.11513-2-leonardo@linux.ibm.com> <4ff1e8e8-929b-9cfc-9bf8-ee88e34de888@nvidia.com> <2533a13f226a6e1fab387669b6cced2aa8d2e129.camel@linux.ibm.com> From: John Hubbard X-Nvconfidentiality: public Message-ID: <48bf32ca-5d3e-5d69-4cd1-6720364a0d81@nvidia.com> Date: Mon, 30 Sep 2019 10:57:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2533a13f226a6e1fab387669b6cced2aa8d2e129.camel@linux.ibm.com> X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL101.nvidia.com (172.20.187.10) To DRHQMAIL107.nvidia.com (10.27.9.16) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1569866375; bh=ida5NqYozcHsuQU0dgyz8EHV8y2ExlP90sInt7HRND4=; h=X-PGP-Universal:Subject:To:CC:References:From:X-Nvconfidentiality: Message-ID:Date:User-Agent:MIME-Version:In-Reply-To: X-Originating-IP:X-ClientProxiedBy:Content-Type:Content-Language: Content-Transfer-Encoding; b=SmdwlCKjTZ+a+Cb3C2kWIEHJFaIrrAUy8mamA5p9yPYcDeKEUc3vBUd9LATvsLusU /XdXUFqrwMc8vNmqfFLjmbm8Ph/KPeIqr0B4ZsqRUDRjfcUisQDTB73NSBVk3a3p8x IzsUs0ly7yhI3/d3xNuFOHshq5QR9xw1S0PXhHTofoCXY74b5xY+iWJ5yCSGuOWHYd VBpMlM3WQFuQiiNxDaD2tJP+7wtdt7XbokYT0dvK54APzUTRbLR2wyKl3do65uGjWF cBcFt/9WpKt6c5n5cl4a37M5zW7VRK91+UYeIxxfQAw7ig06qycHkdqySjZrtEYeOu d4CxRscpuQBgQ== 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 9/30/19 8:14 AM, Leonardo Bras wrote: > On Sun, 2019-09-29 at 15:40 -0700, John Hubbard wrote: >> Hi, Leonardo, > > Hello John, thanks for the feedback. > >> Can we please do it as shown below, instead (compile-tested only)? >> >> This addresses all of the comments that I was going to make about structure >> of this patch, which are: >> >> * The lockless synch is tricky, so it should be encapsulated in function >> calls if possible. > > As I told before, there are cases where this function is called from > 'real mode' in powerpc, which doesn't disable irqs and may have a > tricky behavior if we do. So, encapsulate the irq disable in this > function can be a bad choice. You still haven't explained how this works in that case. So far, the synchronization we've discussed has depended upon interrupt disabling as part of the solution, in order to hold off page splitting and page table freeing. Simply skipping that means that an additional mechanism is required...which btw might involve a new, ppc-specific routine, so maybe this is going to end up pretty close to what I pasted in after all... > > Of course, if we really need that, we can add a bool parameter to the > function to choose about disabling/enabling irqs. >> >> * This is really a core mm function, so don't hide it away in arch layers. >> (If you're changing mm/ files, that's a big hint.) > > My idea here is to let the arch decide on how this 'register' is going > to work, as archs may have different needs (in powerpc for example, we > can't always disable irqs, since we may be in realmode). > > Maybe we can create a generic function instead of a dummy, and let it > be replaced in case the arch needs to do so. Yes, that might be what we need, if it turns out that ppc can't use this approach (although let's see about that). thanks, -- John Hubbard NVIDIA