Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2162235pxb; Mon, 8 Mar 2021 16:24:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJxCwMxPqYLviaaIME1v6bTC8zQYqh9iwRf90YQj/Y4rX/X933iGibNMIR7ApNkyQgvu0fR4 X-Received: by 2002:a05:6402:5255:: with SMTP id t21mr1135583edd.91.1615249465923; Mon, 08 Mar 2021 16:24:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615249465; cv=none; d=google.com; s=arc-20160816; b=SN4Eu3dRuAFFDvc2b9Wn5+2moe9OTfOrz94DQ5yRbD0fdJDdrYuo397nKvVvGzUDS3 W241MwIsbN0B40ENykBOnnvsOS/mfn6+CZhfgWkjWdXQQI1HNzaNqn5D+H6iqhoGNHOO HJGQhQFoaa8m0FiLG4TIGbi9QBQK6QMy8/BARy6ZTuaz7QoaE4uc9BDGb69az3YWaQVJ nSQ3Ze4xxZ9KGZgqRjr8J2tGIiBRFdylaThK1xp6/wyV9TCMce48ZLNGdW+TXzSWP08a SPQuxqBJA1nIApVPoX/M3Q1PE4f9dl30bypHGcGH1NF7d59SRznHbUJJPCqHWwLtMczu INQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=9BKi0RvMI9+mtOhhONNTzxiaCRAoWLB7cadjvrtP4c4=; b=L2ogVjTbdKuwrfRBw/UFoe7eH/16b9aWNMBUICBSWNoQu7o4EXIkPs9+6G0i/7fT7e +B5YkfTyQ3Ub0O5Cb9vCui/1o3K2LLfHPRPsyYCCOtToMNxTH62ACVtxo8EFKZtuZE5T Z3XRpHZ5ER9WE9RlVmwcvtdCm3rBNhTawEyG6/rgx14CNToTe5e7ZD+ft6k5LS0WuhuL yvf93pLF0EhX0OYdArglk6Nw/BdfzSBH9yzKB0yKWuyVpmXK3YtCplhiy11TJ9w6/4Pd RGzDXhb9Y9cHwqM53lkcrTloPyFpo/IV4h3xL7hzCNnwBuiWU+93W2ViT/uZid3v1ram f96Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=bz4V75Jp; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v25si7950431ejw.423.2021.03.08.16.24.02; Mon, 08 Mar 2021 16:24:25 -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=@linux-foundation.org header.s=korg header.b=bz4V75Jp; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232077AbhCIAVx (ORCPT + 99 others); Mon, 8 Mar 2021 19:21:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:48232 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231864AbhCIAVb (ORCPT ); Mon, 8 Mar 2021 19:21:31 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id DD52C64FFD; Tue, 9 Mar 2021 00:21:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1615249289; bh=DlBHQTYx7AJjClppLF+twkS9JNHiruHKDw5scvY5BrA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bz4V75JpPXo1KIN+GkM4xn8NkmqewhCdNlKTr+cJK/BdQsFf98dTcK+7z1R+DP81R 5AcnE/X7h1rlyY07XBIzIE5udXa8itnYRkvfj664sPVLvixjCHP8yGtmg8unzPvWRJ 7F5c0pCJiBLFkS8nUwozNkTIWnPsmhTZRudFJFfA= Date: Mon, 8 Mar 2021 16:21:28 -0800 From: Andrew Morton To: Minchan Kim Cc: linux-mm , LKML , John Dias , Michal Hocko , David Hildenbrand , Jason Baron Subject: Re: [PATCH v2] mm: page_alloc: dump migrate-failed pages Message-Id: <20210308162128.9b4a7d4c1576a72fd4878bdb@linux-foundation.org> In-Reply-To: <20210308202047.1903802-1-minchan@kernel.org> References: <20210308202047.1903802-1-minchan@kernel.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 8 Mar 2021 12:20:47 -0800 Minchan Kim wrote: > alloc_contig_range is usually used on cma area or movable zone. > It's critical if the page migration fails on those areas so > dump more debugging message. > > page refcount, mapcount with page flags on dump_page are > helpful information to deduce the culprit. Furthermore, > dump_page_owner was super helpful to find long term pinner > who initiated the page allocation. > > Admin could enable the dump like this(by default, disabled) > > echo "func dump_migrate_failure_pages +p" > control > > Admin could disable it. > > echo "func dump_migrate_failure_pages =_" > control > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -8453,6 +8453,34 @@ static unsigned long pfn_max_align_up(unsigned long pfn) > pageblock_nr_pages)); > } > > +#if defined(CONFIG_DYNAMIC_DEBUG) || \ > + (defined(CONFIG_DYNAMIC_DEBUG_CORE) && defined(DYNAMIC_DEBUG_MODULE)) > +static DEFINE_RATELIMIT_STATE(alloc_contig_ratelimit_state, > + DEFAULT_RATELIMIT_INTERVAL, DEFAULT_RATELIMIT_BURST); > +int alloc_contig_ratelimit(void) > +{ > + return __ratelimit(&alloc_contig_ratelimit_state); > +} Wow, that's an eyesore. We're missing helpers in the ratelimit code. Can we do something like /* description goes here */ #define RATELIMIT2(interval, burst) ({ static DEFINE_RATELIMIT_STATE(_rs, interval, burst); __ratelimit(_rs); }) #define RATELIMIT() RATELIMIT2(DEFAULT_RATELIMIT_INTERVAL, DEFAULT_RATELIMIT_BURST) > +void dump_migrate_failure_pages(struct list_head *page_list) > +{ > + DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, > + "migrate failure"); > + if (DYNAMIC_DEBUG_BRANCH(descriptor) && > + alloc_contig_ratelimit()) { > + struct page *page; > + > + WARN(1, "failed callstack"); > + list_for_each_entry(page, page_list, lru) > + dump_page(page, "migration failure"); > + } > +} Then we can simply do if (DYNAMIC_DEBUG_BRANCH(descriptor) && RATELIMIT())