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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 757A3C433EF for ; Mon, 13 Sep 2021 15:51:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5649D60F51 for ; Mon, 13 Sep 2021 15:51:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343753AbhIMPwO (ORCPT ); Mon, 13 Sep 2021 11:52:14 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:38106 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230330AbhIMPwA (ORCPT ); Mon, 13 Sep 2021 11:52:00 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B579C21F34; Mon, 13 Sep 2021 15:50:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1631548242; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+eyk10XtROXLts0BsM53ESJTU6x6wdPA46RKx5foHiI=; b=A81Fjnx62iAN1magonQFZvuCwH43fJ6m1MZXiPGdtAXyKPi+1GiHzXFeZNAHC1iyxZMi3o ROCuVtdmZtxJUqa+Ak7iAOsqG2PGcL7+PkYPknJ/uK91C8HW55+04zl0GvoAZ9g59HtbRu wF9UdRKedIC5xaqcC2Gi1UM0o7OIZ0w= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 4045DA3B94; Mon, 13 Sep 2021 15:50:42 +0000 (UTC) Date: Mon, 13 Sep 2021 17:50:41 +0200 From: Michal Hocko To: Mike Kravetz Cc: Vlastimil Babka , Hillf Danton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RESEND 0/8] hugetlb: add demote/split page functionality Message-ID: References: <2d826470-d345-0196-1359-b79ed08dfc66@oracle.com> <02a1a50f-4e7c-4eb7-519c-35b26ec2c6af@oracle.com> <20210907085001.3773-1-hdanton@sina.com> <6c42bed7-d4dd-e5eb-5a74-24cf64bf52d3@oracle.com> <71f855ac-ff61-1eed-454f-909c0e4210b2@suse.cz> <2519e0f8-98ee-6bad-3895-ac733635e5b0@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2519e0f8-98ee-6bad-3895-ac733635e5b0@oracle.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 10-09-21 17:11:05, Mike Kravetz wrote: [...] > @@ -5064,8 +5068,18 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask) > if (did_some_progress > 0 && > should_compact_retry(ac, order, alloc_flags, > compact_result, &compact_priority, > - &compaction_retries)) > + &compaction_retries)) { > + /* > + * In one pathological case, pages can be stolen immediately > + * after reclaimed. It looks like we are making progress, and > + * compaction_retries is not incremented. This could cause > + * an indefinite number of retries. Cap the number of retries > + * for costly orders. > + */ > + if (max_tries && tries > max_tries) > + goto nopage; > goto retry; > + } I do not think this is a good approach. We do not want to play with retries numbers. If we want to go with a minimal change for now then the compaction feedback mechanism should track the number of reclaimed pages to satisfy watermarks and if that grows beyond reasonable (proportionaly to the request size) then simply give up rather than keep trying again and again. -- Michal Hocko SUSE Labs