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 E3C6EC77B7A for ; Thu, 18 May 2023 18:48:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80F3C900004; Thu, 18 May 2023 14:48:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BFE9900003; Thu, 18 May 2023 14:48:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D592900004; Thu, 18 May 2023 14:48:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5E6BF900003 for ; Thu, 18 May 2023 14:48:05 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B2AD7160902 for ; Thu, 18 May 2023 18:48:04 +0000 (UTC) X-FDA: 80804260488.17.797376D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id C5941C0012 for ; Thu, 18 May 2023 18:48:02 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ratNj5tW; spf=pass (imf10.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684435682; a=rsa-sha256; cv=none; b=WCVPlRawKlxKMZXVyofb/gkuqBrOZvd5NhEM5Ng3+taMDg+64lMA7AJ/lnE7Oil4ceB2MZ iqQPF2Py8DjYtZESUyS2/TobbCfKWnmihP6oYhu0PK10SBXse/1d/Vcw2g3mXsnFvn3b2k PLIYUFZUcGRFSv5LmI9+iAHCbFJxSso= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ratNj5tW; spf=pass (imf10.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=1684435682; 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=PwjszGGbFiAKWyCBInDp/gi7XkhqivYocgollkpnG/c=; b=ZEOyCc+3fylUt5w+iA+fTayQxUvk3ZMe30DSFBxWK/QgIJVMA3xz8JisQsohN0G5dTl8g8 373wTMP5qp9dz83uJ1ySQIcWMpcyswQvOt4Q8P67a0XcDqs3kIb3eXUGSetn0aaVbkdzqE J3vCdcNjGfWp1ivU/YCw9Z4fHN9evZo= 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 D5B7661D72 for ; Thu, 18 May 2023 18:48:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5572C433A1 for ; Thu, 18 May 2023 18:48:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684435680; bh=keVuOeJQn7MUYbsAN7orx57MdKZnoEd10BmBQ0B0DpY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ratNj5tWhPL+Rkfvc7CQjH6TZjvjSqavc0NoyncOYcPhC/bKzoaFh9deBcmU/CSUn ns1gjiiVoEmqt789/rq3s899pqu1GJZlN22rBizO5rzYrMDDumrFKRL5hwyzSK/Fmy j7cjAsbqpNBoHSZe5XMPLZlvXCAXQ/+uOLw5Vt0nbMYxU0+02Hz08GX9nKjGFoDj6f zLAMoLTGLxg/Y8MxgCGMHZTK8lLYjmv9T/TH31QxVPDV6j/xTKw5vujQo/cdjj5Djw gv1PnAEYKsvWB4Ej6zrljynyjoc/bb2Hmd87kg4ab3MMPthxUiCp17fDrKhfv1dLPc zWH8zuauNEGUQ== Received: by mail-lj1-f181.google.com with SMTP id 38308e7fff4ca-2ac78bb48eeso25515491fa.1 for ; Thu, 18 May 2023 11:48:00 -0700 (PDT) X-Gm-Message-State: AC+VfDy9twnYgeIWRZD1w4oKBL5ZPHMYzyu5/B0VVai54zTaOCLSFk3A E7RmPYwdwvHfLHGZNjqqcDWigNuAnf4l5lfn/oM= X-Google-Smtp-Source: ACHHUZ5GX32LoEcP1z/j3+D+v55vn3QF43tBqfsGVqTwwnkb8WeJAYPR05RqCn4bpaS7RqDFaBIwUilge1pmtrD6XuE= X-Received: by 2002:a2e:9053:0:b0:2ac:7ab1:a441 with SMTP id n19-20020a2e9053000000b002ac7ab1a441mr11685597ljg.30.1684435678735; Thu, 18 May 2023 11:47:58 -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 11:47:46 -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-Server: rspam08 X-Rspamd-Queue-Id: C5941C0012 X-Stat-Signature: mr18bmx1fiwkt7xbefxh4uw4nmyoqmf1 X-Rspam-User: X-HE-Tag: 1684435682-268112 X-HE-Meta: U2FsdGVkX18CMrisnGQ9Tt2vyaFDQbKvJMTPVtY9PWqUhzSR+DKjrJ88c1ZJd8P620Azs46pQiUdXgl5v3oUoqUgG6oVVK5+VfPU7ZcFDH8whOduk9di5eg7xha/rlwQafDjuOtHChbP9aR2AEApEfdCiLXMTvxIJKZCTvT3+iig3OwCbSI36Gk/Z6wA4Hh5XyBLtZGyXQRR0OybobOUKlOwnNVeogkTcWAHV5nVRVwwdXGzI76+6JH7fgJLbb3TpNeTJ4gjEFqeRXPf/8K5f453dNYYpvpvwLEQvZMgupy1ryQdeYjA0GNPDmivlejgzblNzta1oaqhBhmQSTy8qvjhUBjM8hWQtlMDs7lfLB+cT3cLhn1GxyencAWHqXytcemMQqS6FaSq0hJMD06bMPfxep1b2zKsf6IO7v2h0dnJl6m/zJ5RKOgoGcAj7PQZLaX7tV+pQlQ4VNOuI7PCJrkpI1FPj+eWxruYLT7stArXNr3V8GoHqOjkiULgTunGAr2xpDbuI/XlwsGixnNQBXEx6ozp1NWSjzE/EX9e7628Nk42RswsyYIDXt2vr6W0d6qNXqWCrSjpzJ1tikk+GFwlUl6sZDxUSTdvgxaajGYckW9CzUuKcxR2TsMkb1GK39fBKW/6D3JaVaI0HYobZMdjdiYsh7XtIUIkcoyFAp3fRrf/x/M9UTUCcAQCJ0A/L1QYE2D0gossPClAkPD3gRmwxCowAwUNBcrrd2mZ8V1eEUMWrpbIM3Y62esTQ0uFygnGRWUYFLJ+Xh4vFRrhMvMZu3FHfB9X4z5/xXbZoz0TnwuNyn7d9rMSe5WHdZRNn4+Ue+XcbhKGmejjpNSKDnEup58BGlpcvfYnhl36wmDaj6q0rRgMf9Ug+n68q2Ytl69IfS7A0tb+7v5aiIDlq2zkze64EV4xXDVud3OJJU7/csX+y8c327HZvPVHVb3Z5ZFsqrRHBlx3JrIfo4i KU9CZhIy cumzZfrxiWqd5Om0agXdA+6T8vsHRXP1eG2IBVv2X5Lnvh0bSQGvZGa2tcfci4RZtj5f0/CwNir6keJ3Oq20El+U81sMH+vw24I85zxvBGn9hydhyyxOxa7yR13NnEc9WMPm3DlkvGq4enMQr1ADRUyXBlMxRKBsm7PFyrQNk35bBRJTK2M80jYkklJR0I9azVUoRjqJHebEKvw3zic6wubQbOpANdglrceguFt3o5bNz1gOUwTA7FGSw/ipZ4FZTXcwLgZqUpDqmzbt+WhBWNalWzJhkKn6wNPPimGTqGD5vQUKAqXXX7T600Vn3IDglNxy30+CAfatloPqsMR+wEPlSGMmNELrX4bZBylS/VKS1MrxIqq7PeE3YQBN5lHoDWVd8OzJtlVhw0uyg4ZHnytEaAyXxdrRK/4RPLiCXPsGEk9U= 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 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 planni= ng 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 thi= nk > > > he had some fair points in that thread. > > > > Yes, the API is based on Thomas's suggestion, like 90% from the discuss= ions. > > > > > > > > My own feeling is that the buddy allocator is our tool for allocating > > > larger variable sized physically contiguous allocations, so I'd like = to > > > see something based on that - I think we could do a hybrid buddy/slab > > > 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, so > 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 missed > :) 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 within 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, the tree based allocator can allocate 4MiB for it, and use the rest 1MiB for smaller allocations. Thanks, Song [2] https://lore.kernel.org/linux-mm/20221107223921.3451913-6-song@kernel.o= rg/