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 DF3CBC636CC for ; Thu, 16 Feb 2023 17:45:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 15C9F6B0071; Thu, 16 Feb 2023 12:45:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 10D0A6B0072; Thu, 16 Feb 2023 12:45:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F17CB6B0073; Thu, 16 Feb 2023 12:45:18 -0500 (EST) 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 E24DD6B0071 for ; Thu, 16 Feb 2023 12:45:18 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 880D8C04D1 for ; Thu, 16 Feb 2023 17:45:18 +0000 (UTC) X-FDA: 80473881516.29.DD530E0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf27.hostedemail.com (Postfix) with ESMTP id 8C6F340002 for ; Thu, 16 Feb 2023 17:45:16 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VipjDgL5; spf=pass (imf27.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676569516; 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=2mzxNVMuq5jEQnFVLSN30BEqatt4b1C2xfEjhCs+OpU=; b=Bo+Hgmnw8Vyc6TSTmQ0VH+XPR7STUixfI9MOUv7fWNC3xis7MR68arDHJVBmSWmmuTAYn+ TfBZeOTud/lFmrTXJuTiODNTK2P/d7DunJxEVSpORu9WpFRpMeZhTGBc3wVRxUdVBH83hi KH4M4XNH++JUSRJ0KXdgG2e3Z5zjsZ8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VipjDgL5; spf=pass (imf27.hostedemail.com: domain of mpatocka@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=mpatocka@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676569516; a=rsa-sha256; cv=none; b=UO+aoH+L13DxJN2g71MklBdapo1OiUCpGdbJ4DPY1KTq5i8EXTmL2/7yRdYFeZ3oLii2wR YTp0PerL2oalpegejOsMivPenaY2q7TV3+qwY9gBZ9iyjU69hrS5QoSVcgwfvfK0j57Y41 3EILKt8TONoQfMx6Vfd5NwToXbpyH38= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676569515; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2mzxNVMuq5jEQnFVLSN30BEqatt4b1C2xfEjhCs+OpU=; b=VipjDgL5MOc8Yx2YLr6KwwiYL0IvN9vaUax5FtU94eiyzR5PvEjIKHkOsZoFkuk5Pas48k r1XYtyil1ShK2sYAVEBFOgTXxXk1bXjaMoQRMHBfCllALlTR1wWqSEB1I9DcSYQxA8ZDJw e9+aI4FH2e7BCzSrf3wwRjDbE8kapLQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-441-_BdyFXuUNbSriE5uz1rNgA-1; Thu, 16 Feb 2023 12:45:13 -0500 X-MC-Unique: _BdyFXuUNbSriE5uz1rNgA-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1D27138041D7; Thu, 16 Feb 2023 17:45:12 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (file01.intranet.prod.int.rdu2.redhat.com [10.11.5.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 02756492B15; Thu, 16 Feb 2023 17:45:12 +0000 (UTC) Received: from file01.intranet.prod.int.rdu2.redhat.com (localhost [127.0.0.1]) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4) with ESMTP id 31GHjBfP024047; Thu, 16 Feb 2023 12:45:11 -0500 Received: from localhost (mpatocka@localhost) by file01.intranet.prod.int.rdu2.redhat.com (8.14.4/8.14.4/Submit) with ESMTP id 31GHjBZ0024043; Thu, 16 Feb 2023 12:45:11 -0500 X-Authentication-Warning: file01.intranet.prod.int.rdu2.redhat.com: mpatocka owned process doing -bs Date: Thu, 16 Feb 2023 12:45:11 -0500 (EST) From: Mikulas Patocka X-X-Sender: mpatocka@file01.intranet.prod.int.rdu2.redhat.com To: Yang Shi cc: mgorman@techsingularity.net, agk@redhat.com, snitzer@kernel.org, dm-devel@redhat.com, akpm@linux-foundation.org, linux-block@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [dm-devel] [v2 PATCH 0/5] Introduce mempool pages bulk allocator and use it in dm-crypt In-Reply-To: Message-ID: References: <20230214190221.1156876-1-shy828301@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8C6F340002 X-Rspam-User: X-Stat-Signature: gi7ag5kcm4d3tnprzdtoxg6zh4uopjtq X-HE-Tag: 1676569516-298633 X-HE-Meta: U2FsdGVkX185rJAP9xspLN6zzz7U6zkLw6AORJI3WiPspfakR3FfN93B6O8OzCY6pWEwDi3hVSeC0+9LJIJzfrbj2XnVHLASzGElUoabVKGWLZYC8brXO22l6PwVeXVhtiWWwixSfMpDmPCdTnNdOV7QsyXeXDY6IiLKc9GY+ie/bQ64NodcnWLJjNd8xSq1pzamJBVKi0nw7taAJKuSCyZkswBkRyMwnz0t/nKotkQ3/UsA1qD8UGdyRorMHZosmkx4/t8lbol1MJhKzinFwhuWP7yi/2ga28nesAiJIctdC7sGR5N5Ut8d6ERHg8JJcJKVm38A1Ki/7rATcgD9bqhDCL+nwK/+He/AMn+GwbNOJdXjTkfY3VuWBBk9P+MN/uLP233z1E2cznTKuja//QBJirIytZrE44st/JFq+h0LHUusO5+YU8+FvKYhnVMXs1XhjU6tefjwszHWr2za/8rdlk4M/FQ47rLPsQ5aVZWiDAVTnXHqjwbUZHuNqUAoJnOQljDXDB7MCNS357plvWMNl4NP29NrBpCSSKgw+X3VNzV59h03iT+BF8ENTzilbBJ8AUHFWwwIO5/1sbaIM4yv43Md7lINHAZoyPf1lTUCkhm++8YqZ6G93ldnxQjXCIqh9rp2gpVHsKrowaz1+F8iyvtfCovBhOeK957kbFFmkFz9DEGCAskxVNJ/yYM3VRlFsvgjr0Uu5tlYKhRSIE5IUwjF69hUWPYnftTspRh7FpXZpZ5adDTioayEEWo3hRB6pIOooEJ0WHXTbZn/3Z0mEOytut99PsAV5GYaS3/I7nmfeGV3DCMAtuAvov8CrEhXyO15Mue902dkfP8vt/xpEHIsCqTAqNBOWT73l0s22lq04bBA40MjWQEIZAmqOjJ2DSb/pf7G1GhqB1aj90nfQoqbjfs+PnyPZGzQu8YktnnwPmQ1oVVZA8dCsDOOiRWvMKIFwQN0M+ONtEz p6ySlhvp TRcNsUbX71ohNtwcqL7Us2EvJk103JcCRxVuVThKlp+YFIA2yDm2ikCYAGJAiKnLA+Mil2lG3zx+IMkzabDjssOC/8mBgoIQ6QpKF163CrXuFlk6iNzfiY6htI5SjcX/JUaB8xpmgu8AGaYUMD5E+K6bGFwthbZJdRXL44qSojyVm6HIkzmvqAaQCn0ad0cx3z3SrcAb6RbhdeGRbtCfphkezvf1vHNJkkb/zRR1Fb+4XZwgv4Uyo5/B1NsJOoTXGNkrVmZrQSpakPjkMTiW8d05hy7RUxWFLU+XKhJOWVW0QZSvmZlsIMBjp8g== 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 Wed, 15 Feb 2023, Yang Shi wrote: > On Wed, Feb 15, 2023 at 4:23 AM Mikulas Patocka wrote: > > > > > > > > On Tue, 14 Feb 2023, Yang Shi wrote: > > > > > > > > Changelog: > > > RFC -> v2: > > > * Added callback variant for page bulk allocator and mempool bulk allocator > > > per Mel Gorman. > > > * Used the callback version in dm-crypt driver. > > > * Some code cleanup and refactor to reduce duplicate code. > > > > > > rfc: https://lore.kernel.org/linux-mm/20221005180341.1738796-1-shy828301@gmail.com/ > > > > Hi > > > > This seems like unneeded complication to me. We have alloc_pages(), it can > > allocate multiple pages efficiently, so why not use it? > > The alloc_pages() allocates *contiguous* pages, but dm-crypt doesn't > need contiguous pages at all. This may incur unnecessary compaction It doesn't hurt that the pages are contiguous - and allocating and freeing a few compound pages is even faster than allocating and freeing many 0-order pages. > overhead to the dm-crypt layer when memory is fragmented. The compaction overhead may be suppressed by the GFP flags (i.e. don't use __GFP_DIRECT_RECLAIM). > The bulk allocator is a good fit to this usecase, which allocates > multiple order-0 pages. > > In addition, filesystem writeback doesn't guarantee power-of-2 pages > every time IIUC. But alloc_pages() just can allocate power-of-2 pages. So, we can allocate more compound pages for the non-power-of-2 case - see the next patch that I'm sending. > > > > I suggest to modify crypt_alloc_buffer() to use alloc_pages() and if > > alloc_pages() fails (either because the system is low on memory or because > > memory is too fragmented), fall back to the existing code that does > > mempool_alloc(). > > My PoC patches just did this way, but called bulk allocator. There may > be other potential mepool users as I listed in this cover letter, > which may get benefits from bulk allocator. So introducing a new bulk > mempool API seems better for long run although we just have one user > for now. And it makes other uses easier to gain the benefit by just > calling the new API. This mempool bulk refactoring just makes the code bigger. And it is not needed - dm-crypt can fall-back to non-bulk mempool allocations. In the next email, I'm sending a patch that is noticeably smaller and that uses alloc_pages()/__free_pages(). Mikulas