Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1628752pxb; Thu, 4 Mar 2021 16:54:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJyccqF+HwQ7NSm+Eelx733lTTOogjN12HUN9IsoKZtt5TM9I0WbEJYViEOJwqHhauvF97A7 X-Received: by 2002:a05:6e02:54e:: with SMTP id i14mr6506421ils.136.1614905698954; Thu, 04 Mar 2021 16:54:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614905698; cv=none; d=google.com; s=arc-20160816; b=egdO3k94nBslk6za42R4g2hnDhZFtyFfwl9BjAIqsJRZCxQXb1GBJde2O02nvAydla L30pKVu7yg/dzVYXn58soSu32H6lUouOnYZl5BCTolYCOTjvg/O0z5DH9i56ezAEinjM ky1E3P687YzwdRCxRGN0pKpGatV10sdSdg2hgH7/doCCWz5rl1wKhsceNDp04CiZDVxN vJ3YEpKtsseGLyQ6FW1UD7Bt7Hy51mgyUmal5Io6CcWDGZ41IUpXJnMIvXFJqQMwjZ1N N0BlIxuUiipQv4DWIoramc5sMziqLJfwBqU5as3mDjN8DvPQFODK/uhiHMoTvyBgIyYm gdUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=r4hMSKBkNtrRITzzBe+cMqUl3cO3UFDjYwJAXk9K9SE=; b=K32+BwJhBE9Vp+3cCMHqKMJLxQQZNCeBEcQVtwYzDpwNa+izrJN9Q+gjZqa7JD75sa 2mEDaYWXWt2+gu1/YNyA8ArrRuRipjnkw9JbBoYKa8Fa0b9AswR9ue/b6aS4UkH3O2aS jcIDwtV1JO2OFm+11OcQHv4vIKY7DHLct17dRR0m/h8+mplflEiuu9mqLH8cdV7jg70h sfxxhIbvONroIwDP5yPn8oMVbuXnbCIulDiILDlgM7/nKlG4xBVxxQlo88Ov01wuU3jZ 2vK7cSdU64RR9modAIQomfJ/iO1zcHXt4BanNWK2SXlhDbWTMhjIlPTVp9lgr+JWIyDj qZ/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iqJV8iPD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t15si487491jal.2.2021.03.04.16.54.45; Thu, 04 Mar 2021 16:54:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=iqJV8iPD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234189AbhCDSXk (ORCPT + 99 others); Thu, 4 Mar 2021 13:23:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234207AbhCDSXg (ORCPT ); Thu, 4 Mar 2021 13:23:36 -0500 Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC341C061574 for ; Thu, 4 Mar 2021 10:22:55 -0800 (PST) Received: by mail-pg1-x52a.google.com with SMTP id g4so19462996pgj.0 for ; Thu, 04 Mar 2021 10:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=r4hMSKBkNtrRITzzBe+cMqUl3cO3UFDjYwJAXk9K9SE=; b=iqJV8iPDKudZQtDxcUCimb3iPY6xqF9k/f6jUMMW5GwvCT1YYo6xmfN6X9f7NvMxHH u+VXMjUXW4fLrAD6xu+3BRaUj6Xjc5Xi1ZZBOUIpL3jdiZ+Ttlo5LgHYbaDW9keTV/h8 2EPX+Bq4BVb9R3/iPMS/I5rct4S9ToTdA46XgIW34wpMvZCFhitQq2rRBGFTKM5QLNQR zhBv55y5Gd13HtQ1nR/WxigglGM2zy6Su6IOXQFZN6FWdHqS3mfGFsxxfLYayLQCrxrg mzB+LtEwDEkEi4Mg7KYjSXI9PJj45auYKBBDg1r8n5mJpvmyd3z7PQejuOHKTB5goBKG G1Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=r4hMSKBkNtrRITzzBe+cMqUl3cO3UFDjYwJAXk9K9SE=; b=FD0O2B2vyJiNJ4BHu7p/L8jiuFCFux9jC6+VcuR4u8HzQzPkkf/FFWpL/IFsmIuwWz DKHIFqPhKcZic2xf0RGi+oMpILag7GXL7HJ3jUCpclJHSM0y7T5v9o904/9O5Ci6FyVJ zF0CqH42ajlxoPJFGELoNcPolintZnBG3L1BipKKTYx/ReTfSyQljmfYQfehtc7wuFbP duw85v4IHQAYP5rpS2BpM9mHeSxVBGLkZZq5TmnrM2oRj+tU6cha9/E/X9ax3GjyA8y9 8mbafDyo5+ddSi4EHIhArwCP3XHD8y1aX8gIs3hapliCbywhNQ8jgznHNXoloTouthpY Qnfw== X-Gm-Message-State: AOAM530LSTktU6odg5FwCjA/PB+KN44aWApw0bHBapTzAb+mGCKCdyvW DWy/auS2Wm94yiahPhgZyRs= X-Received: by 2002:aa7:9281:0:b029:1ec:48b2:811c with SMTP id j1-20020aa792810000b02901ec48b2811cmr5005240pfa.18.1614882175190; Thu, 04 Mar 2021 10:22:55 -0800 (PST) Received: from google.com ([2620:15c:211:201:edb1:8010:5c27:a8cc]) by smtp.gmail.com with ESMTPSA id w128sm106609pfw.86.2021.03.04.10.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Mar 2021 10:22:53 -0800 (PST) Sender: Minchan Kim Date: Thu, 4 Mar 2021 10:22:51 -0800 From: Minchan Kim To: David Hildenbrand Cc: Michal Hocko , Andrew Morton , linux-mm , LKML , joaodias@google.com Subject: Re: [PATCH] mm: be more verbose for alloc_contig_range faliures Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 04, 2021 at 10:11:35AM -0800, Minchan Kim wrote: > On Thu, Mar 04, 2021 at 06:23:09PM +0100, David Hildenbrand wrote: > > > > You want to debug something, so you try triggering it and capturing debug > > > > data. There are not that many alloc_contig_range() users such that this > > > > would really be an issue to isolate ... > > > > > > cma_alloc uses alloc_contig_range and cma_alloc has lots of users. > > > Even, it is expoerted by dmabuf so any userspace would trigger the > > > allocation by their own. Some of them could be tolerant for the failure, > > > rest of them could be critical. We should't expect it by limited kernel > > > usecase. > > > > Assume you are debugging allocation failures. You either collect the data > > yourself or ask someone to send you that output. You care about any > > alloc_contig_range() allocation failures that shouldn't happen, don't you? > > > > > > > > > > > > > Strictly speaking: any allocation failure on ZONE_MOVABLE or CMA is > > > > problematic (putting aside NORETRY logic and similar aside). So any such > > > > page you hit is worth investigating and, therefore, worth getting logged for > > > > debugging purposes. > > > > > > If you believe the every alloc_contig_range failure is problematic > > > > Every one where we should have guarantees I guess: ZONE_MOVABLE or > > MIGRAT_CMA. On ZONE_NORMAL, there are no guarantees. > > Indeed. 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 function is based on compact_zone() from compaction.c. */ unsigned int nr_reclaimed; @@ -8522,7 +8523,8 @@ static int __alloc_contig_migrate_range(struct compact_control *cc, NULL, (unsigned long)&mtc, cc->mode, MR_CONTIG_RANGE); } if (ret < 0) { - dump_migrate_failure_pages(&cc->migratepages); + if (ret == -EBUSY && nofail) + dump_migrate_failure_pages(&cc->migratepages); putback_movable_pages(&cc->migratepages); return ret; } @@ -8610,7 +8612,9 @@ int alloc_contig_range(unsigned long start, unsigned long end, * allocated. So, if we fall through be sure to clear ret so that * -EBUSY is not accidentally used or returned to caller. */ - ret = __alloc_contig_migrate_range(&cc, start, end); + ret = __alloc_contig_migrate_range(&cc, start, end, + migratetype == CMA || + zone_idx(cc.zone) == ZONE_MOVABLE); if (ret && ret != -EBUSY) goto done; ret =0;