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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 6925FC433DB for ; Thu, 11 Feb 2021 21:38:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F360B64E45 for ; Thu, 11 Feb 2021 21:38:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F360B64E45 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 832DA8D0007; Thu, 11 Feb 2021 16:38:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BC5F8D0002; Thu, 11 Feb 2021 16:38:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6ABDB8D0007; Thu, 11 Feb 2021 16:38:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0132.hostedemail.com [216.40.44.132]) by kanga.kvack.org (Postfix) with ESMTP id 529A38D0002 for ; Thu, 11 Feb 2021 16:38:28 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 19C5F181AF5CC for ; Thu, 11 Feb 2021 21:38:28 +0000 (UTC) X-FDA: 77807301096.08.F4CB2CB Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf09.hostedemail.com (Postfix) with ESMTP id EA255600249C for ; Thu, 11 Feb 2021 21:38:25 +0000 (UTC) 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 6577CAE91; Thu, 11 Feb 2021 21:38:26 +0000 (UTC) Date: Thu, 11 Feb 2021 22:38:23 +0100 From: Oscar Salvador To: Mike Kravetz Cc: David Hildenbrand , Muchun Song , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 2/2] mm,page_alloc: Make alloc_contig_range handle free hugetlb pages Message-ID: <20210211213823.GB3597@localhost.localdomain> References: <20210208103812.32056-1-osalvador@suse.de> <20210208103812.32056-3-osalvador@suse.de> <5a6c0efb-4667-c382-8c3e-fd95b6ae839e@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a6c0efb-4667-c382-8c3e-fd95b6ae839e@oracle.com> X-Stat-Signature: pski8gdxdkpcfxh6mbij36thu8jwj1xm X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: EA255600249C Received-SPF: none (suse.de>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1613079505-397415 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000191, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 10, 2021 at 05:16:29PM -0800, Mike Kravetz wrote: > Should probably check for -EBUSY as this means someone started using > the page while we were allocating a new one. It would complicate the > code to try and do the 'right thing'. Right thing might be getting > dissolving the new pool page and then trying to isolate this in use > page. Of course things could change again while you are doing that. :( Yeah, I kept the error handling rather low just be clear about the approach I was leaning towards, but yes, we should definitely check for -EBUSY on dissolve_free_huge_page(). And it might be that dissolve_free_huge_page() returns -EBUSY on the old page, and we need to dissolve the freshly allocated one as it is not going to be used, and that might fail as well due to reserves for instance, or maybe someone started using it? I have to confess that I need to check the reservation code closer to be aware of corner cases. We used to try to be clever in such situations in memory-failure code, but at some point you end up thinking "ok, how many retries are considered enough?". That code was trickier as we were handling uncorrected/corrected memory errors, so we strived to do our best, but here we can be more flexible as the whole thing is racy per se, and just fail if we find too many obstacles. I shall resume work early next week. Thanks for the tips ;-) -- Oscar Salvador SUSE L3