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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D47E3C433DB for ; Mon, 15 Feb 2021 12:01:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 506C264E04 for ; Mon, 15 Feb 2021 12:01:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 506C264E04 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=techsingularity.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E1C3C8D00F3; Mon, 15 Feb 2021 07:01:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DCB618D00E6; Mon, 15 Feb 2021 07:01:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D07F88D00F3; Mon, 15 Feb 2021 07:01:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id BAA2F8D00E6 for ; Mon, 15 Feb 2021 07:01:00 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7FBE375A6 for ; Mon, 15 Feb 2021 12:01:00 +0000 (UTC) X-FDA: 77820361080.09.C840D8A Received: from outbound-smtp30.blacknight.com (outbound-smtp30.blacknight.com [81.17.249.61]) by imf21.hostedemail.com (Postfix) with ESMTP id 0D730E007A5D for ; Mon, 15 Feb 2021 12:00:57 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail03.blacknight.ie [81.17.254.16]) by outbound-smtp30.blacknight.com (Postfix) with ESMTPS id CDD12BAACE for ; Mon, 15 Feb 2021 12:00:57 +0000 (GMT) Received: (qmail 27872 invoked from network); 15 Feb 2021 12:00:57 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.22.4]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 15 Feb 2021 12:00:57 -0000 Date: Mon, 15 Feb 2021 12:00:56 +0000 From: Mel Gorman To: Jesper Dangaard Brouer Cc: Chuck Lever , Mel Gorman , Linux NFS Mailing List , "linux-mm@kvack.org" , Jakub Kicinski Subject: Re: alloc_pages_bulk() Message-ID: <20210215120056.GD3697@techsingularity.net> References: <2A0C36E7-8CB0-486F-A8DB-463CA28C5C5D@oracle.com> <20210209113108.1ca16cfa@carbon> <20210210084155.GA3697@techsingularity.net> <20210210124103.56ed1e95@carbon> <20210210130705.GC3629@suse.de> <20210211091235.GC3697@techsingularity.net> <20210211132628.1fe4f10b@carbon> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20210211132628.1fe4f10b@carbon> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0D730E007A5D X-Stat-Signature: 5ct7spnn8adknks3membmg6u6aqkrfek Received-SPF: none (techsingularity.net>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=outbound-smtp30.blacknight.com; client-ip=81.17.249.61 X-HE-DKIM-Result: none/none X-HE-Tag: 1613390457-160588 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, Feb 11, 2021 at 01:26:28PM +0100, Jesper Dangaard Brouer wrote: > > Parameters to __rmqueue_pcplist are garbage as the parameter order changed. > > I'm surprised it didn't blow up in a spectacular fashion. Again, this > > hasn't been near any testing and passing a list with high orders to > > free_pages_bulk() will corrupt lists too. Mostly it's a curiousity to see > > if there is justification for reworking the allocator to fundamentally > > deal in batches and then feed batches to pcp lists and the bulk allocator > > while leaving the normal GFP API as single page "batches". While that > > would be ideal, it's relatively high risk for regressions. There is still > > some scope for adding a basic bulk allocator before considering a major > > refactoring effort. > > The alloc_flags reminds me that I have some asks around the semantics > of the API. I'm concerned about the latency impact on preemption. I > want us to avoid creating something that runs for too long with > IRQs/preempt disabled. > > (With SLUB kmem_cache_free_bulk() we manage to run most of the time with > preempt and IRQs enabled. So, I'm not worried about large slab bulk > free. For SLUB kmem_cache_alloc_bulk() we run with local_irq_disable(), > so I always recommend users not to do excessive bulk-alloc.) > The length of time IRQs/preempt disabled are partially related to the bulk API but the deeper concern is how long the IRQs are disabled within the page allocator in general. Sometimes they are disabled for list manipulations but the duration is longer than it has to be for per-cpu stat updates and that may be unnecessary for all arches and configurations. Some may need IRQs disabled but others may only need preempt disabled for the counters. That's a more serious overall than just the bulk allocator. > For this page bulk alloc API, I'm fine with limiting it to only support > order-0 pages. (This will also fit nicely with the PCP system it think). > Ok. > I also suggest the API can return less pages than requested. Because I > want to to "exit"/return if it need to go into an expensive code path > (like buddy allocator or compaction). I'm assuming we have a flags to > give us this behavior (via gfp_flags or alloc_flags)? > The API returns the number of pages returned on a list so policies around how aggressive it should be allocating the requested number of pages could be adjusted without changing the API. Passing in policy requests via gfp_flags may be problematic as most (all?) bits are already used. -- Mel Gorman SUSE Labs