Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7612987ybl; Tue, 24 Dec 2019 05:48:11 -0800 (PST) X-Google-Smtp-Source: APXvYqxUdou/Rj/XqXZ1QJAaAXRPPDia2XbyldXvnqaBKvtCIuFqqbDdUgFYegIN27X9wwavFzjE X-Received: by 2002:a9d:3b09:: with SMTP id z9mr39019245otb.195.1577195291598; Tue, 24 Dec 2019 05:48:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577195291; cv=none; d=google.com; s=arc-20160816; b=Qmca99WAVpaUKhaFXYcmTB7BS0deR/WoAykDknrXlC3wMl7MRMSxyDv/dfjS8EdgQs tR1/xwjq1iK5J/cVks1jE/KDZdMLEbS0jicUKfYFJ/ryatU8jHJTjmRcH3t3GJYU6SaR RqpCEtJFOqyaV82kAWwmdwBeErG4AdJARqS/iEKnw2Uso8ppUegWW7roONEuFCjA2hNa mQkX/kDVMxWQDLD33slVv9NBbmv57c3/8Lp5jKTPzhZQM2iSVZAwV6mR1cBGMAmEyJ2k gXmq1Q1xtyYfOy/hBPT+AsOqX4hvk7O97CtbsqMiY1HZty2qGer5T/CK28fkTzF8Qlyx WiSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:in-reply-to:cc:references:message-id :date:subject:mime-version:from:content-transfer-encoding :dkim-signature; bh=gJSU2c7V0b8ZdILNENIi9JaOANjv/UG/dY9rvMfObQ0=; b=AqIx8OuSGJKwYfY2e96CbTq8CeGt79/xt0Fm3agkPN7+udQBPRYURpNEcbkrmxxAE2 mpChEFZSh9tJqBnuSnz7+d6HEw0LITTIATWFI0qGyw/zTZY65tAcBIj9oh8+BC0oFzL7 Apg1seN+WIc1QkAHq2qYSItQuy+p45jj8OaYL8USO2TeyuRBUVINpSIPZIm8yeGX5Dj0 HZi8oRrix7BX1diaErD3i8ZmK5fMEBECX18VLMrZVxNyrR3iGVNnzhb0h1CJh1fy4VcW jLd0f8xeuhSiiqKvDrkAiElfpgiEqCvLeqKkjF2g2Rf4G6us+YTwug/99FK/jp9mQ9Zw 69Dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lca.pw header.s=google header.b=a1XflIgS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 194si11147728oii.2.2019.12.24.05.47.59; Tue, 24 Dec 2019 05:48:11 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@lca.pw header.s=google header.b=a1XflIgS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726258AbfLXNrT (ORCPT + 99 others); Tue, 24 Dec 2019 08:47:19 -0500 Received: from mail-qk1-f194.google.com ([209.85.222.194]:40421 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726128AbfLXNrS (ORCPT ); Tue, 24 Dec 2019 08:47:18 -0500 Received: by mail-qk1-f194.google.com with SMTP id c17so16048530qkg.7 for ; Tue, 24 Dec 2019 05:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=gJSU2c7V0b8ZdILNENIi9JaOANjv/UG/dY9rvMfObQ0=; b=a1XflIgSEYNpJvpUhAyvvY/8pqmTpscYLPyOlUzC6qYXGsT/ftktR5ECLrk070j9Zw Qe6KW4fiampfcyY1sdzubGbwR3jBOQ3XqKWA4SHzzAlKVnpibJXXpttbqSVxLW3wU6rm kIlmeHuOexw62UGQESniUTMe2cEa6jZB/DDRR2QuJaJfO+ukdC0uBfc4QGNg9pFJFueo c3NGXtWjcKBjxu+DLtY5rBlhjOFGqozv0V1IqmUc44RSIhOWlRgFo7u08GVro97P8f3A 2FPXjktQebmxkgNmNMHM+qx20hfmZyHYbPGZZiRc3J0lElrF052KAhcVsfwYMURkegtb 8Eeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=gJSU2c7V0b8ZdILNENIi9JaOANjv/UG/dY9rvMfObQ0=; b=PuY5nszATf+L6BQI5k6zKb8DrAKDzLGPAKNkSS4bCgOz5iebdbW0tor3QeO7sUDkNQ UhV50jC0vbBPfL7OS6g2TqKuKGia/aPI1/XxRSABXmT9WnNi5nMGECdNcoDVzM9JuzdA pQNK8e0lDmnP2omrM9DBODWsPiDR9UquDQJ2hrdIysKIZsE8S3vsah6gz+F6YMowM7QJ 7G1MMKiHNmGL3jVWh7DaJWTpSDhuztndFYcW0HwTOr4GbaZxhEUeknRAkpeiexFN8Zm2 6RRDGcVuqa2GAj7LclmBCo0s7vvypQgCeGLAcQDedkGbmqmuM4ppVHUVO+QXmHzY3Lru NJ1A== X-Gm-Message-State: APjAAAVTw5vsH2dlyC22g/6QLGrXzr6rDClge4+ux33gsvVy52u+gMkx U98HCa8ZVTs070ct170rkmU0Jw== X-Received: by 2002:a37:8085:: with SMTP id b127mr30055985qkd.424.1577195237928; Tue, 24 Dec 2019 05:47:17 -0800 (PST) Received: from [192.168.1.183] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id r44sm7586209qta.26.2019.12.24.05.47.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Dec 2019 05:47:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Qian Cai Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] mm/page_owner: print largest memory consumer when OOM panic occurs Date: Tue, 24 Dec 2019 08:47:15 -0500 Message-Id: <5E08DE19-5B71-4245-8908-548BB4FA861F@lca.pw> References: <1577169946.4959.4.camel@mtkswgap22> Cc: Andrew Morton , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-mediatek@lists.infradead.org, wsd_upstream@mediatek.com In-Reply-To: <1577169946.4959.4.camel@mtkswgap22> To: Miles Chen X-Mailer: iPhone Mail (17C54) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Dec 24, 2019, at 1:45 AM, Miles Chen wrote: >=20 > We use kmemleak too, but a memory leakage which is caused by > alloc_pages() in a kernel device driver cannot be caught by kmemleak. > We have fought against this kind of real problems for a few years and=20 > find a way to make the debugging easier. >=20 > We currently have information during OOM: process Node, zone, swap,=20 > process (pid, rss, name), slab usage, and the backtrace, order, and > gfp flags of the OOM backtrace.=20 > We can tell many different types of OOM problems by the information > above except the alloc_pages() leakage. >=20 > The patch does work and save a lot of debugging time. > Could we consider the "greatest memory consumer" as another useful=20 > OOM information? This is rather situational considering there are memory leaks here and there= but it is not necessary that straightforward as a single place of greatest c= onsumer. The other question is why the offensive drivers that use alloc_pages() repea= tedly without using any object allocator? Do you have examples of this in dr= ivers that could happen?=