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 93C1DC4332F for ; Fri, 21 Oct 2022 09:19:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2278E8E0002; Fri, 21 Oct 2022 05:19:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1B11C8E0001; Fri, 21 Oct 2022 05:19:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 078958E0002; Fri, 21 Oct 2022 05:19:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E8BBC8E0001 for ; Fri, 21 Oct 2022 05:19:15 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BB5B880CF7 for ; Fri, 21 Oct 2022 09:19:15 +0000 (UTC) X-FDA: 80044407870.11.E4D119C Received: from outbound-smtp31.blacknight.com (outbound-smtp31.blacknight.com [81.17.249.62]) by imf09.hostedemail.com (Postfix) with ESMTP id DC084140006 for ; Fri, 21 Oct 2022 09:19:14 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail06.blacknight.ie [81.17.255.152]) by outbound-smtp31.blacknight.com (Postfix) with ESMTPS id 7010CC0F8F for ; Fri, 21 Oct 2022 10:19:13 +0100 (IST) Received: (qmail 8314 invoked from network); 21 Oct 2022 09:19:13 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 21 Oct 2022 09:19:13 -0000 Date: Fri, 21 Oct 2022 10:19:11 +0100 From: Mel Gorman To: Yang Shi 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 Subject: Re: [PATCH 2/4] mm: mempool: introduce page bulk allocator Message-ID: <20221021091911.ak3a7a3wr3qcbe3b@techsingularity.net> References: <20221005180341.1738796-1-shy828301@gmail.com> <20221005180341.1738796-3-shy828301@gmail.com> <20221013123830.opbulq4qad56kuev@techsingularity.net> <20221017094132.vnanndrwa2yn7qcw@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666343955; 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; bh=2XhPHMqDldgN1ze7MKDZr13yMbKq5wFeQ65+oI+zCJM=; b=lfQOgMQ/oo5ymbPcf7EumcnK04Mzvp7/LhM6jIf8sVHRkmfsjapcTaPhG7tz/E2bdNb6dF MHPzVPa7Dx5QIy4AQtH1zChEB8iaDpzAOWZq+uNTydnLwV5XYOC03CIQCYrsyyNX+AUvx0 av4W0+9KyemtzGhLfjQpeKAhL+u0ihw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.62 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666343955; a=rsa-sha256; cv=none; b=xrHIdpXzvf5GH9HvSir06x/U4TrPtb51jNgexaY4n0Y1hBlejMI/HDwl5kAETgYp/BOCzX awqgD74rgNukmH+3nL6pVyRKJQmpRm9huBQ/xwdxJwHI9caeZRYiQue68unm+7VXLt54R2 +tOLiOy0CUETTkh2R0ZtmJ3eerPH1r8= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: DC084140006 X-Rspam-User: Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.62 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net; dmarc=none X-Stat-Signature: 3qwyaf4pugatrsh4yux9fc3njzzg498y X-HE-Tag: 1666343954-900460 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 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. -- Mel Gorman SUSE Labs