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 0A1BEFA372B for ; Thu, 17 Oct 2019 07:38:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CC83F214E0 for ; Thu, 17 Oct 2019 07:38:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CC83F214E0 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 71F758E0005; Thu, 17 Oct 2019 03:38:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CFF98E0001; Thu, 17 Oct 2019 03:38:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BDA28E0005; Thu, 17 Oct 2019 03:38:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 3308D8E0001 for ; Thu, 17 Oct 2019 03:38:54 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id C5289180AE81E for ; Thu, 17 Oct 2019 07:38:53 +0000 (UTC) X-FDA: 76052474946.29.push99_87d3ef6b7463d X-HE-Tag: push99_87d3ef6b7463d X-Filterd-Recvd-Size: 5046 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 17 Oct 2019 07:38:53 +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 3F507308624A; Thu, 17 Oct 2019 07:38:52 +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 76B9D600C4; Thu, 17 Oct 2019 07:38:49 +0000 (UTC) Subject: Re: [PATCH V2] mm/page_alloc: Add alloc_contig_pages() To: Michal Hocko Cc: Anshuman Khandual , 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: <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> <20191017073413.GC24485@dhcp22.suse.cz> From: David Hildenbrand Organization: Red Hat GmbH Message-ID: <31505b6d-1c09-4fcc-a079-3fbb3c96da48@redhat.com> Date: Thu, 17 Oct 2019 09:38:48 +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: <20191017073413.GC24485@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.49]); Thu, 17 Oct 2019 07:38:52 +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:34, Michal Hocko wrote: > On Thu 17-10-19 09:21:24, David Hildenbrand wrote: >> 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) > > thx for the correction. > >>> 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)." > > This is again an implementation detail and quite a confusing one to > whoever not familiar with the MM internals. And to be fair even a proper > alignment doesn't give you any stronger guarantee as long as the > allocation operates on non movable zones anyway. > To be honest, I'd not suggest to anyone to use this function with nr_pages not being a power of two, and I already explained why. I prefer to spill that out than having people complain afterwards. Yes it's an implementation detail users should be aware of until reworked. But I think we talked about this here for way too long, so I am fine with either. -- Thanks, David / dhildenb