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.2 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 1AE20C433DB for ; Wed, 17 Feb 2021 13:43:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD82E64DCF for ; Wed, 17 Feb 2021 13:43:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233153AbhBQNnb (ORCPT ); Wed, 17 Feb 2021 08:43:31 -0500 Received: from mx2.suse.de ([195.135.220.15]:46016 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233401AbhBQNnJ (ORCPT ); Wed, 17 Feb 2021 08:43:09 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 55C69B75E; Wed, 17 Feb 2021 13:42:28 +0000 (UTC) Date: Wed, 17 Feb 2021 14:42:26 +0100 From: Oscar Salvador To: Michal Hocko Cc: Andrew Morton , Mike Kravetz , David Hildenbrand , Muchun Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages Message-ID: <20210217134221.GA32488@linux> References: <20210217100816.28860-1-osalvador@suse.de> <20210217100816.28860-2-osalvador@suse.de> 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) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 17, 2021 at 02:30:43PM +0100, Michal Hocko wrote: > On Wed 17-02-21 11:08:15, Oscar Salvador wrote: > I do not think fallback to a different zone is ok. If yes then this > really requires a very good reasoning. alloc_contig_range is an > optimistic allocation interface at best and it shouldn't break carefully > node aware preallocation done by administrator. Yeah, previous version (RFC) was more careful with that. I somehow thought that it might be ok to fallback to other nodes in case we failed to allocate on the preferred nid. I will get RFC handling back wrt. allocation once I gather more feedback. > > > Note that gigantic hugetlb pages are fenced off since there is a cyclic > > dependency between them and alloc_contig_range. > > Why do we need/want to do all this in the first place? When trying to allocate a memory chunk with alloc_contig_range, it will fail if it ever sees a Hugetlb page because isolate_migratepages_range() does not "recognize" those for migration (or to put it different, does not know about them). Given that HugeTLB pages can be migrated or dissolved if free, it makes sense to enable isolate_migratepages_range() to recognize HugeTLB pages in order to handle them, as it currently does with LRU and Movable pages. -- Oscar Salvador SUSE L3