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 59622C7EE23 for ; Thu, 18 May 2023 19:03:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6107280001; Thu, 18 May 2023 15:03:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D10D7900003; Thu, 18 May 2023 15:03:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BD97D280001; Thu, 18 May 2023 15:03:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id AC2E3900003 for ; Thu, 18 May 2023 15:03:22 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 62A65ADC37 for ; Thu, 18 May 2023 19:03:22 +0000 (UTC) X-FDA: 80804299044.18.D035392 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 17E6B40029 for ; Thu, 18 May 2023 19:03:19 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Q9o775Rj; spf=pass (imf17.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684436600; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0Y0RqGagcYjlQAFm/IWSrNSzj7W+UdS1UVZleO5FMag=; b=rb5PYGt4i+Zx7Mmm9qPdgMvCqizrVr/lLWGThf9lD4kVFZXdopC/1GUAugzX7CGTcDyL8N l6QXkCXXyb+P9bRflhBSkMNXbBclMWj4MOZ7hqzgwyvnrMYS2Ao8ur5Bu2pVUlgQR/kOV7 ioBWMhFLeETdHjcsJlC9X5Z2qIzJ4vU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684436600; a=rsa-sha256; cv=none; b=r74jJyvuGv6L8vGikYskvD31KoJMLI1JeoaHOw2eCajGq+blREAxRCmbTyacp/rjn6XqzT ULLvEQd6soN7t/pJEsaMpIhG3Qq6qrpSMYHgRgc9AZlSM9kM4frWYlqyOAhl8IH1GVInu8 PwmuldP9gW67pk9ic3C+X6uDtTdt9sI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Q9o775Rj; spf=pass (imf17.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3F01E60BF0 for ; Thu, 18 May 2023 19:03:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28BD4C433A8 for ; Thu, 18 May 2023 19:03:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684436598; bh=34OAiZIPKDw+WhaknFtzgMGGRM/uM4kd2z9SISgsEqo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Q9o775RjZoJw0WQin4BFUO3ZA5OnWpQgL1Qn8JGF4VaTWwMo4/agvV3GzFmNmdCED kGoBngLWXC0fRFbJGbZllNRgvY3oilqV3BHnUH+9zRXMdAbH2S/ZXRoQRm7JcTaWBh PX4BtGKTg8J3a0NEMfbS23q3bKcu4NaOMDQ6QlyfOms0NMjgAPr0KWa3ivz4pExqCu 50eyJ9xXLD9v6V2322Cx3gtCQN3jajySQ9JQDJ2AeGo64Syg/FZa0kzwq39VkNVMT2 qkdaZ0TFry0ar8aOTSYbxatuW92n2rtkeSwOqVudIkN+5j7nfE9hDYiF9+XjbxjvyE aqVW1nzg9FPUQ== Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-4f3a7241c0aso1028218e87.1 for ; Thu, 18 May 2023 12:03:18 -0700 (PDT) X-Gm-Message-State: AC+VfDx/iuMih0YhQNRNwOb+xM8v168EwZhUtARnEMqnORj1tp07DZ31 yoJAd5dCCPhfBFap6qK9wqxIOiH8rQ4XbcswLTs= X-Google-Smtp-Source: ACHHUZ7b0p7p/AkK558EZSzBH5ajI7jacbEjGMGiWiG+ep93ZOt+Cxs36e3TVpl/Kpn+kZoWAJzUBIM6K4QHTzToIrE= X-Received: by 2002:a2e:9dca:0:b0:2a9:ee54:289f with SMTP id x10-20020a2e9dca000000b002a9ee54289fmr12043370ljj.13.1684436596130; Thu, 18 May 2023 12:03:16 -0700 (PDT) MIME-Version: 1.0 References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> <20230518152354.GD4967@kernel.org> In-Reply-To: From: Song Liu Date: Thu, 18 May 2023 12:03:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() To: Kent Overstreet Cc: Mike Rapoport , linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 17E6B40029 X-Rspam-User: X-Stat-Signature: x9rfmncicfes37qoinicd3s87rpd1k8e X-Rspamd-Server: rspam03 X-HE-Tag: 1684436599-186662 X-HE-Meta: U2FsdGVkX1/sheknburYw8+JKKmOWHanndbgaIA95M0RbFRQoBgjwBnNPymLjDeCsjih27wZQlpqkKIhglrbyfT57DnaNBbh1OGGJcSHMMu9/XCZBxzK0vdc2bZMUPfchN7z+o0EhlXMOSein9Wp5aQimDVh2SWI1wDbF/u3TC8tpFG7rRlojszN90Qq5ScI7EnED9cSEEnnGbDgxb36ZX7LCXyWAIDKcvtMzREWsw7iQObX59hjEXKHsilgVMswSGBMsiVDglCnOjbiO81g1V8v81vLcrxRjISe0/KyFGu0SNxUGGFxy7wzVVmglMYaGrraV17M8U0zQDck47x/rXXtDJrwqhvaou4v2RU6SDOeKONZCJ+jCk/gJJ404rxqArS/Ccj94ZIf/XKvFi+U9k9zW7MLmHDM/fu49Fctbe9zJ0IXk2L4G2tOThtgdAVgB5w4Qngft3KV0+AC6/LbP2AIz+WH0zvpbL5+27fV51TMAmh56KjRVazL+CUwKYslZmS9OwNguzbvGSM2ROrNjYpkJ7eTdATw/vLUlZXX6RK5+e0RI2b6fyxdD/hbv9zh0nSkyTW5T5DoAnTxJUVddX0JH3j9/aNY7XupXJjEfgiuQVa6ZmCSejZGZCfZbghgOw91b9dm1U8q0jXh7jnPY0p53dLNmE+e7b+V9bUypybsxggD4W7fgqL3NaS3tomCHOXTe4RAePaKF1IH560biafvBoKO3PV+7iPZNx/vAXWlDQLc8+hDufGc4v8jTyeHILSXRB7i3i87oZrkvF+0dMkJwbfDnM7c+CyGVTsq9o4ywRgzhNvCIw3yWbBtxrEUqwXV7IBSUf68KgQqGPQ6mydvn5Ksw+PZBrsT7JoVfJnEnfpkQm7OKz2nebx4ZzA39a9/UN/01tFvU5ytEc4B2P5848/vFjL0CNvle7Rp7FSVKVL+lN3Y/BnXXLRVAnzOyqEMKQKuukKbodmyA/a SaGWa46W inoX0fC7Ys9v9i6KGMYhJic7MdjoNyq98m9rGMQnZxV9waL+bWHTwu0MId/ONpEMSmshoKDpPJe5XMmkA1qpDoCCeCHUgUhDQZFUgZtAcQZjQc8rZI+Nc6CAIntsF8rV2Y5U1AJxsifXErm06jAnIOQyox2+0mTMLY+pLC/pQ7/caRiqBG1DOc3cY2UZ5A9JGoEQld0V4+MBAeXUxAXqPfABrMyZjcp3FukOT+zqmAOA13CNDeTnxa24N8mW7ficnutPtaiDMtUdFy1zNNaN9oUdu5fVf914eT8+fVqG6lvudM45qkfm6xilQ533q5lBCUnY4jl/FEr394RvFIeXqkM0Hs8wM3YLLs/gXrQv+P5OQgdaFwBlIk4s1VkkGfgh3SBJrSZEfbAI/gn+OJQiP3EZ+XP0IOBcq1HlnxGqb4Xnbpmo= 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, May 18, 2023 at 11:47=E2=80=AFAM Song Liu wrote: > > On Thu, May 18, 2023 at 10:24=E2=80=AFAM Kent Overstreet > wrote: > > > > On Thu, May 18, 2023 at 10:00:39AM -0700, Song Liu wrote: > > > On Thu, May 18, 2023 at 9:48=E2=80=AFAM Kent Overstreet > > > wrote: > > > > > > > > On Thu, May 18, 2023 at 09:33:20AM -0700, Song Liu wrote: > > > > > I am working on patches based on the discussion in [1]. I am plan= ning to > > > > > send v1 for review in a week or so. > > > > > > > > Hey Song, I was reviewing that thread too, > > > > > > > > Are you taking a different approach based on Thomas's feedback? I t= hink > > > > he had some fair points in that thread. > > > > > > Yes, the API is based on Thomas's suggestion, like 90% from the discu= ssions. > > > > > > > > > > > My own feeling is that the buddy allocator is our tool for allocati= ng > > > > larger variable sized physically contiguous allocations, so I'd lik= e to > > > > see something based on that - I think we could do a hybrid buddy/sl= ab > > > > allocator approach, like we have for regular memory allocations. > > > > > > I am planning to implement the allocator based on this (reuse > > > vmap_area logic): > > > > Ah, you're still doing vmap_area approach. > > > > Mike's approach looks like it'll be _much_ lighter weight and higher > > performance, to me. vmalloc is known to be slow compared to the buddy > > allocator, and with Mike's approach we're only modifying mappings once > > per 2 MB chunk. > > > > I don't see anything in your code for sub-page sized allocations too, s= o > > perhaps I should keep going with my slab allocator. > > The vmap_area approach handles sub-page allocations. In 5/5 of set [2], > we showed that multiple BPF programs share the same page with some > kernel text (_etext). > > > Could you share your thoughts on your approach vs. Mike's? I'm newer to > > this area of the code than you two so maybe there's an angle I've misse= d > > :) > > AFAICT, tree based solution (vmap_area) is more efficient than bitmap > based solution. > > First, for 2MiB page with 64B chunk size, we need a bitmap of > 2MiB / 64B =3D 32k bit =3D 4k bytes > While the tree based solution can adapt to the number of allocations with= in > This 2MiB page. Also, searching a free range within 4kB of bitmap may > actually be slower than searching in the tree. > > Second, bitmap based solution cannot handle > 2MiB allocation cleanly, > while tree based solution can. For example, if a big driver uses 3MiB, th= e > tree based allocator can allocate 4MiB for it, and use the rest 1MiB for > smaller allocations. Missed one: Third, bitmap based solution requires a "size" parameter in free(). It is a= n overhead for the user. Tree based solution doesn't have this issue. Thanks, Song > > [2] https://lore.kernel.org/linux-mm/20221107223921.3451913-6-song@kernel= .org/