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.4 required=3.0 tests=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 DB0B3C10DCE for ; Thu, 12 Mar 2020 17:17:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9496C2067C for ; Thu, 12 Mar 2020 17:17:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="LBoFZXya" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9496C2067C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 00A396B0010; Thu, 12 Mar 2020 13:17:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFD3D6B0032; Thu, 12 Mar 2020 13:17:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E122D6B0036; Thu, 12 Mar 2020 13:17:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id CAC876B0010 for ; Thu, 12 Mar 2020 13:17:37 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 846D18147 for ; Thu, 12 Mar 2020 17:17:37 +0000 (UTC) X-FDA: 76587366954.11.smell54_4281769c60326 X-HE-Tag: smell54_4281769c60326 X-Filterd-Recvd-Size: 5455 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Thu, 12 Mar 2020 17:17:36 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id b5so7487253qkh.8 for ; Thu, 12 Mar 2020 10:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=jNz3IrFgPeotxDLNaXTICEUp/RnRWRjsOnVPCR+thno=; b=LBoFZXyaqhI+wrfyV+JgFdECjctTdkD2NLPfW0UefrCclVuDzNLgMftJt7wePOin+m GYCLQTjFK9OKRcikgaMB6TZrU4/32wc7kJmLl3k66rVME286eUq+XtTdrQEXGwp+2UE9 IoRtplyaoIatnd7VSBGe49Mk2dnK+ynNnvR5lazFHP8HlKx6vzTIyBlxxEW95/jMHfXg gGpybedoLh0hzhQrXvVi190UFh5WgV1YNJ3vHJFlsAwJ5dSoRNr6fV2ANfpzvh1drYj4 Wj8xPoGeoTlu0SOfO9z/cG7aO0NaGpEx9wfMe9LoTymeqvcPxqYF5KTRttUHZB4Trrae m/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=jNz3IrFgPeotxDLNaXTICEUp/RnRWRjsOnVPCR+thno=; b=fHfae7WNmT+20lWAErYgkenHIpEmCr3hSlz82AVzkIb7u69zCbVyjeLImhoMpBj7ZN tWU3iuaMWnYPSNqnNuev8p371unnbhGjjHr6JQ8okXY8pN3OHSfQYcoqgU8gIibqRQ3f PRQdhFqXCyjotnGC7VHb6xTqIMfChvMTZE/N35iRB9Hf+odOpkUvU+y+vDGvwqEYTw7W AG9zfjDwWa4MY9A+RjPOoikesgFpzDh6+ZOc7DkyFs6QGJ0TIV2S3LQrYbnrIxzVniAq sPWAJ9ztn/zULsrODTncUPCNh5yfV+Zfj1gN/bG4WdT2VBG67HGexblRVzQQ+tvnQ/OC 69TA== X-Gm-Message-State: ANhLgQ2TfbSsTMX3txxuEH3BS77+/quaepESVQnVasQ9XHqkHZuBMiEx w3AOSISXNk59aiMGHizsySt2dg== X-Google-Smtp-Source: ADFU+vtW5dsy1G4ib2/EXTBUeblL8Qau/zrPbOpFbNGasj8QDK9MzB6BcBkp4LKFA9nfntvXkIwwaA== X-Received: by 2002:a05:620a:112c:: with SMTP id p12mr9067500qkk.307.1584033455959; Thu, 12 Mar 2020 10:17:35 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-68-57-212.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.57.212]) by smtp.gmail.com with ESMTPSA id s49sm10076169qtc.29.2020.03.12.10.17.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 12 Mar 2020 10:17:35 -0700 (PDT) Received: from jgg by mlx.ziepe.ca with local (Exim 4.90_1) (envelope-from ) id 1jCRSg-0000u8-Fq; Thu, 12 Mar 2020 14:17:34 -0300 Date: Thu, 12 Mar 2020 14:17:34 -0300 From: Jason Gunthorpe To: Steven Price Cc: Jerome Glisse , Ralph Campbell , "Felix.Kuehling@amd.com" , Philip Yang , John Hubbard , "amd-gfx@lists.freedesktop.org" , "linux-mm@kvack.org" , "dri-devel@lists.freedesktop.org" , Christoph Hellwig Subject: Re: [PATCH] mm/hmm: Simplify hmm_vma_walk_pud slightly Message-ID: <20200312171734.GT31668@ziepe.ca> References: <5bd778fa-51e5-3e0c-d9bb-b38539b03c8d@arm.com> <20200312102813.56699-1-steven.price@arm.com> <20200312142749.GM31668@ziepe.ca> <58e296a6-d32b-bb37-28ce-ade0f784454d@arm.com> <20200312151113.GO31668@ziepe.ca> <689d3c56-3d19-4655-21f5-f9aeab3089df@arm.com> <20200312163734.GR31668@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 Thu, Mar 12, 2020 at 05:02:18PM +0000, Steven Price wrote: > > Having the walker deref the pointer and pass the value it into the ops > > for use rather than repeatedly de-refing an unlocked value seems like > > a much safer design to me. > > Yeah that sounds like a good idea. Ok.. let see when I get this hmm & odp stuff cleared off > > I also didn't quite understand why walk_pte_range() skipped locking > > the pte in the no_vma case - I don't get why vma would be related to > > locking here. > > The no_vma case is for walking the kernel's page tables and they may have > entries that are not backed by struct page, so there isn't (reliably) a PTE > lock to take. Oh, that is an interesting bit of insight.. > > I also saw that hmm open coded the pte walk, presumably for > > performance, so I was thinking of adding some kind of pte_range() > > callback to avoid the expensive indirect function call per pte, but > > hmm also can't have the pmd locked... > > Yeah the callback per PTE is a bit heavy because of the indirect function > call. I'm not sure how to optimise it beyond open coding at the PMD level. > One option would be to provide helper functions to make it a bit more > generic. > > Do you have an idea of what pte_range() would look like? Basically just pass in the already mapped pte array just like is already done at the tail of the pmd The reason to do it like this is so that the common code in the walker can correctly prove the pmd is pointing at a pte before trying to map it. This is complicated, and hmm at least already got it wrong when trying to open code at the PMD level. Jason