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.2 required=3.0 tests=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 25BB5FA372B for ; Thu, 17 Oct 2019 07:21:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E90E620820 for ; Thu, 17 Oct 2019 07:21:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E90E620820 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AFDEF8E0005; Thu, 17 Oct 2019 03:21:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AAE098E0001; Thu, 17 Oct 2019 03:21:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C2A58E0005; Thu, 17 Oct 2019 03:21:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 753318E0001 for ; Thu, 17 Oct 2019 03:21:30 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id E57D0181AEF31 for ; Thu, 17 Oct 2019 07:21:29 +0000 (UTC) X-FDA: 76052431098.13.power89_8175389cf8546 X-HE-Tag: power89_8175389cf8546 X-Filterd-Recvd-Size: 4171 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Oct 2019 07:21:29 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 635F33090FD6; Thu, 17 Oct 2019 07:21:28 +0000 (UTC) Received: from [10.36.117.42] (ovpn-117-42.ams2.redhat.com [10.36.117.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7F990600C8; Thu, 17 Oct 2019 07:21:25 +0000 (UTC) Subject: Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages() To: Michal Hocko , Anshuman Khandual Cc: 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 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> <20191017071129.GB24485@dhcp22.suse.cz> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Thu, 17 Oct 2019 09:21:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <20191017071129.GB24485@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.43]); Thu, 17 Oct 2019 07:21:28 +0000 (UTC) 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 17.10.19 09:11, Michal Hocko wrote: > 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 s/alignement/alignment/ and "the PFN is guaranteed to be aligned to nr_pages" (the address is aligned to nr_pages*PAGE_SIZE) > nr_pages (e.g. 1GB request would be aligned to 1GB). > I'd probably add "This function will miss allocation opportunities if nr_pages is not a power of two (and the implicit alignment is bogus)." -- Thanks, David / dhildenb