Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp604556pxf; Wed, 10 Mar 2021 12:59:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJxU/miZtPX2C2I3yzOZURDaexCTLfmPXI/YCaNU2pyy8YCujHoVXoPv/r3K1FaX3Jb0xtXW X-Received: by 2002:a17:907:10c1:: with SMTP id rv1mr316038ejb.5.1615409994469; Wed, 10 Mar 2021 12:59:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615409994; cv=none; d=google.com; s=arc-20160816; b=aXMVNHVGSu+eN0bvZ60pS5FRmTyTZo81ABF7FsSaYH42QMCKfzW8EcRd2ffHIdESGP F8X3ue+cwtSwmKCn6QEoGQJR7Xoc8gGDvUhwvPb1kTMKHGKl3cEXymzhitHa0YXlhZ2A agCHp0MJq7Aaz5MY7IHvLDgjRh2RJOwWTeRY3RgzdWo4GhS4bzRRaOh/7OrzV1aBLo/x 0GlvPD5hUIUAzRCg0w14pMKrmRP2sJWnfiyeEIEdLupX7mN39MaCIOPfzP5o+svMiTcX 8BaO4LlDHEmOcXppYjNpWBLDq3kgcoY53Df77OJ/+XUCDUz4Cr9Y1+4wpCJMKQ60Pxrl a51Q== 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=X6FLoxQMDtPEeUUpOEFBZFSq2OdX2HW/nsaz91SgUoQ=; b=wo5ESw/WdmzT5F1YCjxhLGW+HKyr56/rTw245NpWMG4Br/86GPiYhYPc8aDC9F89sR k8e9sL5J61Gp8aCSNe5RTOWFbscq7ZsAJJU1a0Iq0xrZ9I9A4Fpc6WOUEdSRi6at8Kc+ sJv0YNcIiGrTCa3k3r9Aq6HmDPfwkr3oGY2g0C7vbhL/c+4J2lMnZ92BLtAogRQINc4z pwNXuKl2tr/2ZBvlXiQsONJqYv+1yc9vVIJxj3t689VdlDODTPkc1zMSKMSrnzVi2PmG I9Y9LCoIp5Fqb5RHiZxA4whD/BO76KOFRiDqYAU9vu3Q5AabDyhApdo9XlLPnZH3F68K bw3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=Pzd+NJwu; 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 e22si361953edu.45.2021.03.10.12.59.32; Wed, 10 Mar 2021 12:59:54 -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=Pzd+NJwu; 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 S231400AbhCJU47 (ORCPT + 99 others); Wed, 10 Mar 2021 15:56:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:60252 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230521AbhCJU4d (ORCPT ); Wed, 10 Mar 2021 15:56:33 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9997564EE8; Wed, 10 Mar 2021 20:56:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1615409771; bh=VVx5ZS51pRRZ4Kk2g9iYDAMVtDpyywK24kFljFq/lUE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Pzd+NJwuI3bJfWQoBjUnXiggyLHtJjbt1dV+HJlQTLJ5cOrrBcNgrYCW4N6QeG6kb AbnC9hY/E8KQY6uIupWFP1khFCouvNWf7Du3EzMJ7L1cJzMLPWUq1vTqGvDz/W9aE0 YVWQBNKZSu7dU3x+Gbcprv7XSNRkDkzPdiAMTtM4= Date: Wed, 10 Mar 2021 12:56:09 -0800 From: Andrew Morton To: Minchan Kim Cc: linux-mm , LKML , John Dias , Michal Hocko , David Hildenbrand , Jason Baron Subject: Re: [PATCH v3] mm: page_alloc: dump migrate-failed pages Message-Id: <20210310125609.359888dc65562fbed4b1f088@linux-foundation.org> In-Reply-To: <20210310180104.517886-1-minchan@kernel.org> References: <20210310180104.517886-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 Wed, 10 Mar 2021 10:01:04 -0800 Minchan Kim wrote: > Currently, debugging CMA allocation failures is quite limited. > The most commong source of these failures seems to be page > migration which doesn't provide any useful information on the > reason of the failure by itself. alloc_contig_range can report > those failures as it holds a list of migrate-failed pages. > > 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. > > The reason it approach with dynamic debug is the debug message > could emit lots of noises as alloc_contig_range calls more > frequently since it's a best effort allocator. > > There are two ifdefery conditions to support common dyndbg options: > > - CONFIG_DYNAMIC_DEBUG_CORE && DYNAMIC_DEBUG_MODULE > It aims for supporting the feature with only specific file > with adding ccflags. > > - CONFIG_DYNAMIC_DEBUG > It aims for supporting the feature with system wide globally. > > A simple example to enable the feature: > > 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 I think the changelog is out of sync. Did you mean "alloc_contig_dump_pages" here? > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -8453,6 +8453,27 @@ 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 void alloc_contig_dump_pages(struct list_head *page_list) > +{ > + DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, > + "migrate failure"); > + > + if (DYNAMIC_DEBUG_BRANCH(descriptor)) { > + struct page *page; > + > + WARN(1, "failed callstack"); > + list_for_each_entry(page, page_list, lru) > + dump_page(page, "migration failure"); > + } > +} I doubt if everyone is familiar with dynamic debug. It might be kind to add a little comment over this, telling people how to turn it on and off.