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=-2.5 required=3.0 tests=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 6218EFA372A for ; Wed, 16 Oct 2019 15:45:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B29B20640 for ; Wed, 16 Oct 2019 15:45:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B29B20640 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B70328E0005; Wed, 16 Oct 2019 11:45:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AFA7A8E0001; Wed, 16 Oct 2019 11:45:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BF868E0005; Wed, 16 Oct 2019 11:45:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 740FC8E0001 for ; Wed, 16 Oct 2019 11:45:49 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 1D697247A for ; Wed, 16 Oct 2019 15:45:49 +0000 (UTC) X-FDA: 76050073218.06.hall62_6cef32554e736 X-HE-Tag: hall62_6cef32554e736 X-Filterd-Recvd-Size: 4755 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Wed, 16 Oct 2019 15:45:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D1E46B12C; Wed, 16 Oct 2019 15:45:46 +0000 (UTC) Date: Wed, 16 Oct 2019 17:45:45 +0200 From: Michal Hocko To: Anshuman Khandual Cc: David Hildenbrand , linux-mm@kvack.org, Mike Kravetz , Andrew Morton , Vlastimil Babka , David Rientjes , Andrea Arcangeli , Oscar Salvador , Mel Gorman , Mike Rapoport , Dan Williams , Pavel Tatashin , Matthew Wilcox , linux-kernel@vger.kernel.org Subject: Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages() Message-ID: <20191016154545.GF317@dhcp22.suse.cz> References: <1571223765-10662-1-git-send-email-anshuman.khandual@arm.com> <40b8375c-5291-b477-1519-fd7fa799a67d@redhat.com> <20191016115119.GA317@dhcp22.suse.cz> <20191016124149.GB317@dhcp22.suse.cz> <97cadd99-d05e-3174-6532-fe18f0301ba7@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97cadd99-d05e-3174-6532-fe18f0301ba7@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 16-10-19 21:01:19, Anshuman Khandual wrote: > > > On 10/16/2019 06:11 PM, Michal Hocko wrote: > > On Wed 16-10-19 14:29:05, David Hildenbrand wrote: > >> On 16.10.19 13:51, Michal Hocko wrote: > >>> On Wed 16-10-19 16:43:57, Anshuman Khandual wrote: > >>>> > >>>> > >>>> On 10/16/2019 04:39 PM, David Hildenbrand wrote: > >>> [...] > >>>>> Just to make sure, you ignored my comment regarding alignment > >>>>> although I explicitly mentioned it a second time? Thanks. > >>>> > >>>> I had asked Michal explicitly what to be included for the respin. Anyways > >>>> seems like the previous thread is active again. I am happy to incorporate > >>>> anything new getting agreed on there. > >>> > >>> Your patch is using the same alignment as the original code would do. If > >>> an explicit alignement is needed then this can be added on top, right? > >>> > >> > >> Again, the "issue" I see here is that we could now pass in numbers that are > >> not a power of two. For gigantic pages it was clear that we always have a > >> number of two. The alignment does not make any sense otherwise. > > ALIGN() does expect nr_pages two be power of two otherwise the mask > value might not be correct, affecting start pfn value for a zone. > > #define ALIGN(x, a) __ALIGN_KERNEL((x), (a)) > #define __ALIGN_KERNEL(x, a) __ALIGN_KERNEL_MASK(x, (typeof(x))(a) - 1) > #define __ALIGN_KERNEL_MASK(x, mask) (((x) + (mask)) & ~(mask)) Yes it doesn't really provide a sensible result but does it matter? > >> What I'm asking for is > >> > >> a) Document "The resulting PFN is aligned to nr_pages" and "nr_pages should > >> be a power of two". > > > > OK, this makes sense. > Sure, will add this to the alloc_contig_pages() helper description and > in the commit message as well. > > > > >> b) Eventually adding something like > >> > >> if (WARN_ON_ONCE(!is_power_of_2(nr_pages))) > >> return NULL; > > > > I am not sure this is really needed. > > > Just wondering why not ? Ideally if we are documenting that nr_pages should be > power of two, then we should abort erring allocation request with an warning. Is > it because allocation can still succeed for non-power-of-two requests despite > possible problem with mask and alignment ? Hence there is no need to abort it. What would we do about the warning? There are only three ways to go about this a) reguire power of two nr_pages and always align to that b) do not restrict nr_pages and align implicitly to what makes sense (power of two on proper size and arbitrary page aligned otherwise) and c) allow an explicit alignment. The simplest way forward is b) because that doesn't really require any code changes. And I thought the main point of this patch was to provide something as simple as possible. a) would be only slightly more complicated but I am wondering why should be restrict the size of the allocation when there is nothing inherent to do so. -- Michal Hocko SUSE Labs