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 36A5AC4CECE for ; Thu, 17 Oct 2019 07:11:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D67932082C for ; Thu, 17 Oct 2019 07:11:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D67932082C 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 2519A8E0005; Thu, 17 Oct 2019 03:11:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2018B8E0001; Thu, 17 Oct 2019 03:11:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 118CF8E0005; Thu, 17 Oct 2019 03:11:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0178.hostedemail.com [216.40.44.178]) by kanga.kvack.org (Postfix) with ESMTP id DEB7A8E0001 for ; Thu, 17 Oct 2019 03:11:33 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 72D7E6418 for ; Thu, 17 Oct 2019 07:11:33 +0000 (UTC) X-FDA: 76052406066.20.match35_2aa6be6e7e32d X-HE-Tag: match35_2aa6be6e7e32d X-Filterd-Recvd-Size: 3177 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Oct 2019 07:11:32 +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 09BBEB3B1; Thu, 17 Oct 2019 07:11:31 +0000 (UTC) Date: Thu, 17 Oct 2019 09:11:29 +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: <20191017071129.GB24485@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: 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 Thu 17-10-19 10:44:41, Anshuman Khandual wrote: [...] > Does this add-on documentation look okay ? Should we also mention about the > possible reduction in chances of success during pfn block search for the > non-power-of-two cases as the implicit alignment will probably turn out to > be bigger than nr_pages itself ? > > * Requested nr_pages may or may not be power of two. The search for suitable > * memory range in a zone happens in nr_pages aligned pfn blocks. But in case > * when nr_pages is not power of two, an implicitly aligned pfn block search > * will happen which in turn will impact allocated memory block's alignment. > * In these cases, the size (i.e nr_pages) and the alignment of the allocated > * memory will be different. This problem does not exist when nr_pages is power > * of two where the size and the alignment of the allocated memory will always > * be nr_pages. I dunno, it sounds more complicated than really necessary IMHO. Callers shouldn't really be bothered by memory blocks and other really deep implementation details.. Wouldn't be the below sufficient? The allocated memory is always aligned to a page boundary. If nr_pages is a power of two then the alignement is guaranteed to be to the given nr_pages (e.g. 1GB request would be aligned to 1GB). -- Michal Hocko SUSE Labs