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=-12.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 89463C433E0 for ; Mon, 8 Mar 2021 13:22:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 19A4B6519D for ; Mon, 8 Mar 2021 13:22:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 19A4B6519D 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 7DB558D002C; Mon, 8 Mar 2021 08:22:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78B568D001D; Mon, 8 Mar 2021 08:22:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62C758D002C; Mon, 8 Mar 2021 08:22:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0087.hostedemail.com [216.40.44.87]) by kanga.kvack.org (Postfix) with ESMTP id 4AF1B8D001D for ; Mon, 8 Mar 2021 08:22:20 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 04C41365A for ; Mon, 8 Mar 2021 13:22:20 +0000 (UTC) X-FDA: 77896770840.25.D6C7E97 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 0E2A38019155 for ; Mon, 8 Mar 2021 13:22:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615209738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QepiH7o0LvrwYirRzj8uzBG9m05jsx4NbX/GyZA7UMw=; b=Pici/6Z5Ahk6+yAu6cCGzslRqMPPX/SVlzr6J8dUenZ8ADm8dVG8XAjCHF9oYw0lQjn8NR XeybpjUEGsVep0apZfb1gh1/RhdPl/dn2K6q/6xxYeVEhr1oV6nPQHjuIjKeLpthU1fWel ix9Z3ISugDzP1+ULCPle4xERhhkFL34= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-533-jP6MmbyxP72SCDAGql5zqg-1; Mon, 08 Mar 2021 08:22:16 -0500 X-MC-Unique: jP6MmbyxP72SCDAGql5zqg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3BF761084D69; Mon, 8 Mar 2021 13:22:15 +0000 (UTC) Received: from [10.36.113.123] (ovpn-113-123.ams2.redhat.com [10.36.113.123]) by smtp.corp.redhat.com (Postfix) with ESMTP id CB21861F55; Mon, 8 Mar 2021 13:22:13 +0000 (UTC) Subject: Re: [PATCH] mm: be more verbose for alloc_contig_range faliures To: Michal Hocko , Minchan Kim Cc: Andrew Morton , linux-mm , LKML , joaodias@google.com References: From: David Hildenbrand Organization: Red Hat GmbH Message-ID: Date: Mon, 8 Mar 2021 14:22:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: 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.15 X-Stat-Signature: 4ebzrfntpkehj6ehrq83ubq34ft34gq8 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0E2A38019155 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf08; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615209733-859221 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 08.03.21 13:49, Michal Hocko wrote: > On Thu 04-03-21 10:22:51, Minchan Kim wrote: > [...] >> How about this? >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 238d0fc232aa..489e557b9390 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -8481,7 +8481,8 @@ static inline void dump_migrate_failure_pages(struct list_head *page_list) >> >> /* [start, end) must belong to a single zone. */ >> static int __alloc_contig_migrate_range(struct compact_control *cc, >> - unsigned long start, unsigned long end) >> + unsigned long start, unsigned long end, >> + bool nofail) > > This sounds like a very bad idea to me. Your nofail definition might > differ from what we actually define as __GFP_NOFAIL but I do not think > this interface should ever promise anything that strong. > Sure movable, cma regions should effectively never fail but there will > never be any _guarantee_ for that. While there are no guarantees, we want to make such allocations as likely as possible to succeed. Not succeeding should be the corner case and is worth investigating. > > Earlier in the discussion I have suggested dynamic debugging facility. > Documentation/admin-guide/dynamic-debug-howto.rst. Have you tried to > look into that direction? Did you see the previous mail this is based on: https://lkml.kernel.org/r/YEEUq8ZRn4WyYWVx@google.com I agree that "nofail" is misleading. Rather something like "dump_on_failure", just a better name :) -- Thanks, David / dhildenb