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 40499EB64D7 for ; Mon, 26 Jun 2023 13:19:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D403D8D0003; Mon, 26 Jun 2023 09:19:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CF1708D0001; Mon, 26 Jun 2023 09:19:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BB8EA8D0003; Mon, 26 Jun 2023 09:19:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id ACCAE8D0001 for ; Mon, 26 Jun 2023 09:19:28 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 55D8C140760 for ; Mon, 26 Jun 2023 13:19:28 +0000 (UTC) X-FDA: 80944955616.06.ED30159 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id BD6D2C001C for ; Mon, 26 Jun 2023 13:19:25 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=K0c36mOH; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687785566; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1lIwl3IXt/Q2BlcHHaTxdvpn5Ox21y8UfooBHZkSajE=; b=hYM2l+i4Sa3CtWAtxGQE0hN+oQtLxQ8x+1B2qDHqZ3aXnMDK+eF4AwhReIiknHnGUjTDor 8sijV13p77kNgU3lt8Wg9KbmNG0yq0/jg7ZM/wxZogE1kyuulWg4tVQ+XqO8/7oKxonK09 6lecWEds1U143lq9lvGAoQUCueZsAII= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687785566; a=rsa-sha256; cv=none; b=QNirJRKNtwaERTOY8AaF/g2nM7g1nSG9pEdiUTrz2TNfinKvLgOxkt4duXbOVKTI/jEath 28EnHFNu1qjMoNtnJQGOZl+Yh4YtFEyT5QY1rxZOkSyZ2pYwGL5hXhPvaHY88kdHMXlTkQ PZxkisvbaOc91OIeinMpc0SX/GR1mS0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=K0c36mOH; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1lIwl3IXt/Q2BlcHHaTxdvpn5Ox21y8UfooBHZkSajE=; b=K0c36mOHX6SJCWJPfezVusm6MV 2iEzGAkU+cd0aS8rTCMxDX6mKsSV+y0RE6E8OHqde0YgSJK5xZIQZPOD9SIUfjjXPqEowS/ReggR6 4zG1Qb5gd86rkAGhrNJQQpaBLMbc8j1TerHCIAXMYn/wyvjmN97cxWAG6lKnpIiOYv7eW5zY0sTHP fgg1yCVmyFEUmlXJyN0/nka82X4UHVCIcwrhpK/XYKiycfbeP799kiJ0su1NyXme3NRUGJ413OcgR huR19idds4/k753xtk3ZTiEY+WOeyVFEUtwVgSmy0r7FKbLukwz2kRd7R0cm7X9uSHL9u5Njus9uI LbbvNthQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qDm7h-001kJr-9Z; Mon, 26 Jun 2023 13:19:17 +0000 Date: Mon, 26 Jun 2023 14:19:17 +0100 From: Matthew Wilcox To: Danilo Krummrich Cc: Peng Zhang , maple-tree@lists.infradead.org, linux-mm@kvack.org, Andrew Morton , "Liam R. Howlett" , linux-kernel@vger.kernel.org, Peng Zhang , David Airlie , Boris Brezillon Subject: Re: [PATCH v2 14/16] maple_tree: Refine mas_preallocate() node calculations Message-ID: References: <20230612203953.2093911-1-Liam.Howlett@oracle.com> <20230612203953.2093911-15-Liam.Howlett@oracle.com> <26d8fbcf-d34f-0a79-9d91-8c60e66f7341@redhat.com> <43ce08db-210a-fec8-51b4-351625b3cdfb@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43ce08db-210a-fec8-51b4-351625b3cdfb@redhat.com> X-Rspamd-Queue-Id: BD6D2C001C X-Rspam-User: X-Stat-Signature: 6kiwzf53w3e7q754wnnsge3bwgbcojmh X-Rspamd-Server: rspam03 X-HE-Tag: 1687785565-297988 X-HE-Meta: U2FsdGVkX1+pCM9pPJqiR//Me02DeIR5Vf8CrufhDO6O2E5H+RycAI31jg6pNRY4izm22QYC0CR4d48yzbYn6tTNLecDPJVrhJ02Yqtw4nHwiSKS95r5pvsb9coT7sB7UeFOFOwIvxUw4PQl3zY1qwWj5n4FBsnxMpB6ySot6yZ+Y9Yd5CtbbfcYVIeJFWAhS/qHhxMvGbvtKmwjJM1CWqV4brHn2Hb10I/fAp815AbXNg3nubKurJLuNplQIXjYO6s6s8kMxej0+U7XUWZx+yfCqii1BK1t9KydcjEcZaZQdHl+7zIazw3YxqEy3Cfo/LyF4a1ikWRViQleMNH+2jWoK0sm5cvc/5MznYujkJgipy2fek/rcgaT7OLXSSZO/FnaX5hJIsxl58oZj4zCa2fS6TPTPgekQVozY9T1qGsm/SCl707DWj+VyX7cCgHUPTCg8Y42xRexfsVzEiU25nOffss5sTfQSVdL6n835WDvnzPUqEc1ZLWedgaJls84+cKDSIflhDnEdLAvH0RsaC4zSs4RlLBex4dv12yzB1CDGFIjuHCepQEWiVDBcYV0CYQ0Lf75Zkqyg+hECPUXtGz6+ZWCHqiksBs7DYcOWapsipfz0hQYkT6iAY7Nn53l9uN2vfnCtyJggxLRTpYm6kbJ4C8cNZPzfc1ZXDFIyHVfuMpPUY0xccbmyReYaZlIFn2LJqxlCXstbEZR1PIkhLAbh5K37Kt8PpXpTHpLKc2PONCknUayRt4QZ4rWvbUJo84Zt+yTJ/6SbilFgnUp9zZV7yFzHcweYNfWMV5Y7cykax7q2/Ts6PM+1T7qnPI6qGH9pcps+vQHSXR8Hv0yZr9i9ux59oo4VSHpe17k6g47HHPmW3LcKdWvpXtvN5o6jLs8tCf61luQyWj3FgybsTb1LIJ2nO/SFgNbSDZPjXBtCLCU/YGPQixgjfBSGjlU7nd5SRYanPYhyhgYYfa 9b0zdq1s GpuSS54mXCbS3FmB7VdOA2XtXSxNpvi7R2d0QMTqivR6VQAv9zc9+fXrLkj1QBw5FCMMcZasjXCo0oCTjs67VxspLg6yrhktyzZN68Mibeik/WN2eooKLWv1Qw9sBsi6wxUdDcwPzABhOInZwIy+QvVoknA1Gjr0GmZAfzyEeQqt0J9cDS2V/0wr1Tw== 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 Mon, Jun 26, 2023 at 02:38:06AM +0200, Danilo Krummrich wrote: > On the other hand, unless I miss something (and if so, please let me know), > something is bogus with the API then. > > While the documentation of the Advanced API of the maple tree explicitly > claims that the user of the API is responsible for locking, this should be > limited to the bounds set by the maple tree implementation. Which means, the > user must decide for either the internal (spin-) lock or an external lock > (which possibly goes away in the future) and acquire and release it > according to the rules maple tree enforces through lockdep checks. > > Let's say one picks the internal lock. How is one supposed to ensure the > tree isn't modified using the internal lock with mas_preallocate()? > > Besides that, I think the documentation should definitely mention this > limitation and give some guidance for the locking. > > Currently, from an API perspective, I can't see how anyone not familiar with > the implementation details would be able to recognize this limitation. > > In terms of the GPUVA manager, unfortunately, it seems like I need to drop > the maple tree and go back to using a rb-tree, since it seems there is no > sane way doing a worst-case pre-allocation that does not suffer from this > limitation. I haven't been paying much attention here (too many other things going on), but something's wrong. First, you shouldn't need to preallocate. Preallocation is only there for really gnarly cases. The way this is *supposed* to work is that the store walks down to the leaf, attempts to insert into that leaf and tries to allocate new nodes with __GFP_NOWAIT. If that fails, it drops the spinlock, allocates with the gfp flags you've specified, then rewalks the tree to retry the store, this time with allocated nodes in its back pocket so that the store will succeed.