Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp164763imu; Thu, 3 Jan 2019 16:36:27 -0800 (PST) X-Google-Smtp-Source: ALg8bN6YKrZXrajmsGKRL5nb2hPVSwY3E9E85fYMGrOVCrdKYWxw3wHLptukKTLZ7KuJeADuPEo1 X-Received: by 2002:a63:66c6:: with SMTP id a189mr18972325pgc.167.1546562187715; Thu, 03 Jan 2019 16:36:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546562187; cv=none; d=google.com; s=arc-20160816; b=H0/KZHS6siDCD0wgCCCOBx7lZyskXS+KsuHCEt0oyqoEabuH950tGBwgXStQ6sR96+ 3aNUdzs8GgYNKBJ0VNEK4QWZpGygUaAsWSjxc6FWkOoheikCq9hQalKMhoJ5F+0r39tu 6UlkXeWySrng09w0ibWV0/F25wqp1ecjRTF60y2lCUYowKAk4ub/+S5rvFs4uVCqQ5L7 Vb5ISeKnHAhd8wTfVUcU71YbQuqpFcaqmjMfotfDpEhhUjCXZiP0NVpMtfPb7CgbowMx VV/XTedWhcZdOIeOdFtDkyKAo8iPK4ouu09hvtDYPGkX8FqEylSrfz4DsH1FU9kBJGbs Hipw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=8mMgC8GmOHtqD9z8mBxr2YjJ+hisdlslFbZ9G59A0/k=; b=T/h9IMjn33ziypKLn/tBkMizIgdazhfREf4oPUS1zYMUti9Bq4hg1S7gjf++fEyAtf dNkDAnSGC7d1vvpxstB4PHTtovNrJnwW78+ke8zCC+x9q8+rLtbhUOkiIr9YpK1alj+D svEkCLgQl2+Vu/b58c/DSJrO22QcSpsoRbu/tXEBFfAaBiAMXKjgc5FGiUch9lRuiJFo v8B13U7AfPqm8/HBOfvOyLyzXE0vsi6Mm7DGMi+S/QqgSCcrbaOolZ9r/SdJi0dKGWf2 ZIpnPwl6DwOyrBz09fDlUEv43zpvgM7XatyTXudPBLQ2LtCJKgZ1AJ/Gfemxk2biuIUW 7G7Q== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a64si1638014pge.124.2019.01.03.16.36.10; Thu, 03 Jan 2019 16:36:27 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727162AbfACUWk (ORCPT + 99 others); Thu, 3 Jan 2019 15:22:40 -0500 Received: from mx2.suse.de ([195.135.220.15]:50758 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726946AbfACUWj (ORCPT ); Thu, 3 Jan 2019 15:22:39 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E27ADAE43; Thu, 3 Jan 2019 20:22:37 +0000 (UTC) Date: Thu, 3 Jan 2019 21:22:35 +0100 From: Michal Hocko To: Qian Cai Cc: akpm@linux-foundation.org, Pavel.Tatashin@microsoft.com, mingo@kernel.org, mgorman@techsingularity.net, iamjoonsoo.kim@lge.com, tglx@linutronix.de, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3] mm/page_owner: fix for deferred struct page init Message-ID: <20190103202235.GE31793@dhcp22.suse.cz> References: <20181220185031.43146-1-cai@lca.pw> <20181220203156.43441-1-cai@lca.pw> <20190103115114.GL31793@dhcp22.suse.cz> <20190103165927.GU31793@dhcp22.suse.cz> <5d8f3a98-a954-c8ab-83d9-2f94c614f268@lca.pw> <20190103190715.GZ31793@dhcp22.suse.cz> <62e96e34-7ea9-491a-b5b6-4828da980d48@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62e96e34-7ea9-491a-b5b6-4828da980d48@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 03-01-19 14:53:47, Qian Cai wrote: > On 1/3/19 2:07 PM, Michal Hocko wrote> So can we make the revert with an > explanation that the patch was wrong? > > If we want to make hacks to catch more objects to be tracked then it > > would be great to have some numbers in hands. > > Well, those numbers are subject to change depends on future start_kernel() > order. Right now, there are many functions could be caught earlier by page owner. > > kmemleak_init(); [...] > sched_init_smp(); The kernel source dump will not tell us much of course. A ball park number whether we are talking about dozen, hundreds or thousands of allocations would tell us something at least, doesn't it. Handwaving that it might help us some is not particurarly useful. We are already losing some allocations already. Does it matter? Well, that depends, sometimes we do want to catch an owner of particular page and it is sad to find nothing. But how many times have you or somebody else encountered that in practice. That is exactly a useful information to judge an ugly ifdefery in the code. See my point? -- Michal Hocko SUSE Labs