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 78230C433FE for ; Fri, 21 Oct 2022 21:04:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBE7E8E0002; Fri, 21 Oct 2022 17:04:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E6DED8E0001; Fri, 21 Oct 2022 17:04:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5CB68E0002; Fri, 21 Oct 2022 17:04:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C6C698E0001 for ; Fri, 21 Oct 2022 17:04:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9D4CF12041F for ; Fri, 21 Oct 2022 21:04:49 +0000 (UTC) X-FDA: 80046185898.11.C6B95C5 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf23.hostedemail.com (Postfix) with ESMTP id 4208E140019 for ; Fri, 21 Oct 2022 21:04:48 +0000 (UTC) Received: by mail-pl1-f179.google.com with SMTP id p3so2486868pld.10 for ; Fri, 21 Oct 2022 14:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ufCCYZYJTmJF/KoW5M3amrstoH4BcMXNIbfmJhiw4Bg=; b=WCWaYaayvJhFN0nzxYZ8rTHbSJb3QZ8teTfyxYm1ciVC4ozBAjqHfy5axAMQ+Lq1pz wMmHX/otXDp+ixHCVLZitVt/EsirR80dPz75DR/89XspfmMN7qtcsOop1T0ETvSY1ESK duNo6HAR+TD2Z4ee2LnD33fhQNuEeB16NFirodfgKS1WdurxWUvd5yENnrQVhk3YvCWk 4JO7UxIDGEXfH5uQLzODMbz9w8rXiJ8WE+ETjtpZCEaovHQE4jB+uXUKjsXpihDskgpa 3gZQ8lQ6EJrraUf3tqB7IcM/Qjs+N6bOlr2EMQE5qoAp1Z/DrRwkvXIQKc6yGK+p5CmM /jEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ufCCYZYJTmJF/KoW5M3amrstoH4BcMXNIbfmJhiw4Bg=; b=n43aZ2zHFpOJi2w+E6MeKKY1okPCrBTSOqZ3ip1A6UjYlKzVMmaWq6VmknHeL+fg8o vBKlkHtmpQO/t8bXqqTUtSyo+RPJKXPv+h290Yn5B9IbM+07XvJqZ7Yzzeobcrh9Swip /Pt6X9MiEmENigByTORYEKkrhTl/ovgqqKq9P89oUFxstchzXXDYla2ElnC3EdTA9RZp UNdJZ2Nghvk3pa2/eNSuAAyQMB1pHEW72qZEvD/xZX7PSYW2etrWmjgvuM+oWWmXqoCk nOGrpOAmXgSqpVOfsFyYeq3AxXIFVJYe4nwtI2rz3U5nlPl56eABhOtARXpkT7Vr0tO1 S62w== X-Gm-Message-State: ACrzQf2rdlA4Yd105WCR1gtKUbwny+OrMGicJE5QkJguMPL+FCQmucEA U1ABZgVTpxPdeeHNj78BAmxhXnrD80lCOY8Adg0= X-Google-Smtp-Source: AMsMyM5tsrngLoCck9omAqu1bf1kz4Ah2EpMQMR6bhFE6MpEItn2IXmD213rWwn/DZs1vJCr8D+09/EppIvZSTFyUfI= X-Received: by 2002:a17:902:d512:b0:181:f1f4:fcb4 with SMTP id b18-20020a170902d51200b00181f1f4fcb4mr21208456plg.102.1666386287303; Fri, 21 Oct 2022 14:04:47 -0700 (PDT) MIME-Version: 1.0 References: <20221005180341.1738796-1-shy828301@gmail.com> <20221005180341.1738796-3-shy828301@gmail.com> <20221013123830.opbulq4qad56kuev@techsingularity.net> <20221017094132.vnanndrwa2yn7qcw@techsingularity.net> <20221021091911.ak3a7a3wr3qcbe3b@techsingularity.net> In-Reply-To: <20221021091911.ak3a7a3wr3qcbe3b@techsingularity.net> From: Yang Shi Date: Fri, 21 Oct 2022 14:04:34 -0700 Message-ID: Subject: Re: [PATCH 2/4] mm: mempool: introduce page bulk allocator To: Mel Gorman Cc: agk@redhat.com, snitzer@kernel.org, dm-devel@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666386288; a=rsa-sha256; cv=none; b=sMGL/EOYaSV51LzPo1O2ZxwaGTJHjnJynzKMs674I3PCllZ0jsZVCXiMpWc4BssNJr2thx w1UnOBNLOMwRW4xTkZLlbqSmKIv5Nb6IMlJIjseEFroysi7Ns68eA1TQc5mk1Pnzkpz+FN M/CF5GYk2vwFLaEm/gUxE3THtjt5yKE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WCWaYaay; spf=pass (imf23.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666386288; 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=ufCCYZYJTmJF/KoW5M3amrstoH4BcMXNIbfmJhiw4Bg=; b=QFyhgZcxVa4qfHNEHcIhTHjILpzTrFjeVFRuExHgdJLwLthshthT1i7eaMjrWrIDq3ZHkF 3GKdsY3Q5GN7s0qohfi0RDw5Bm7s+/RalT3VchiVHKx9HNwoZZsdh2EjBqio5m5MY6LPzd IN/1nHRAmE6j797EwrKtlNsjPxQzEkQ= Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WCWaYaay; spf=pass (imf23.hostedemail.com: domain of shy828301@gmail.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=shy828301@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: wtbd446wfb6ksdahsfrefcn7ygkc4ooj X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4208E140019 X-Rspam-User: X-HE-Tag: 1666386288-89571 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Oct 21, 2022 at 2:19 AM Mel Gorman wrote: > > On Tue, Oct 18, 2022 at 11:01:31AM -0700, Yang Shi wrote: > > > > Yeah, I didn't think of a better way to pass the pages to dm-crypt. > > > > > > > > > > > > > > How about this > > > > > > > > > > 1. Add a callback to __alloc_pages_bulk() that takes a page as a > > > > > parameter like bulk_add_page() or whatever. > > > > > > > > > > 2. For page_list == NULL && page_array == NULL, the callback is used > > > > > > > > > > 3. Add alloc_pages_bulk_cb() that passes in the name of a callback > > > > > function > > > > > > > > > > 4. In the dm-crypt case, use the callback to pass the page to bio_add_page > > > > > for the new page allocated. > > > > > > > > Thank you so much for the suggestion. But I have a hard time > > > > understanding how these work together. Do you mean call bio_add_page() > > > > in the callback? But bio_add_page() needs other parameters. Or I > > > > misunderstood you? > > > > > > > > > > I expected dm-crypt to define the callback. Using bio_add_page > > > directly would not work as the bulk allocator has no idea what to pass > > > bio_add_page. dm-crypt would likely need to create both a callback and an > > > opaque data structure passed as (void *) to track "clone" and "len" > > > > I see. Yeah, we have to pass the "clone" and "len" to the callback via > > pool_data. It should not be hard since dm-crypt already uses > > crypt_config to maintain a counter for allocated pages, we should just > > need to pass the struct to the callback as a parameter. > > > > But I'm wondering whether this is worth it or not? Will it make the > > code harder to follow? > > > > A little because a callback is involved but it's not the only place in the > kernel where a callback is used like this and a comment should suffice. It > should be faster than list manipulation if nothing else. Mostly, I'm wary > of adding the first user of the list interface for the bulk allocator that > does not even want a list. If there isn't a user of the list interface > that *requires* it, the support will simply be deleted as dead code. Thanks, I see your point. Will work on the new version to implement the callback approach. > > -- > Mel Gorman > SUSE Labs