From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932169AbdK0Sxw (ORCPT ); Mon, 27 Nov 2017 13:53:52 -0500 Received: from out0-248.mail.aliyun.com ([140.205.0.248]:58864 "EHLO out0-248.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752982AbdK0Sx2 (ORCPT ); Mon, 27 Nov 2017 13:53:28 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R311e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03292;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---.9WXSr7P_1511808795; Subject: Re: [RFC PATCH 1/2] lib: debugobjects: export max loops counter To: Waiman Long , tglx@linutronix.de Cc: linux-kernel@vger.kernel.org References: <1510947833-116482-1-git-send-email-yang.s@alibaba-inc.com> <8ea5263b-6733-78fa-f6bd-331eedb39da5@redhat.com> From: "Yang Shi" Message-ID: <2747ec3e-e915-2e85-ce89-0f38e21eaec9@alibaba-inc.com> Date: Tue, 28 Nov 2017 02:53:15 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <8ea5263b-6733-78fa-f6bd-331eedb39da5@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/27/17 10:08 AM, Waiman Long wrote: > On 11/27/2017 12:53 PM, Yang Shi wrote: >> Hi Waiman & tglx, >> >> I'm not sure who is the maintainer for lib/debugobjects.c now, I'm >> supposed tglx still is, however, get_maintainer.pl told me Waiman is >> the most active developer of this, so added Waiman in this loop in >> case he didn't see the patches on LKML. >> >> Thanks, >> Yang >> >> On 11/17/17 11:43 AM, Yang Shi wrote: >>> Currently max chain counter is exported to sysfs, it just record the > > It is the debugfs, which is different from sysfs. Will correct it. > >>> counter of inner loop, however, there might be significant iterations of >>> external loop then it may take significant amount of time to finish all >>> of the checks. This may cuase lockup on !CONFIG_PREEMPT kernel build >>> occasionally. >>> >>> Record the counter of the max loops then export to sysfs so that the >>> user can be aware of the real overhead. >>> >>> Then the output of /sys/kernel/debug/debug_objects/stats looks like: >>> >>> max_chain :121 >>> max_loops :543267 >>> warnings :0 >>> fixups :0 >>> pool_free :1764 >>> pool_min_free :341 >>> pool_used :86438 >>> pool_max_used :268887 >>> objs_allocated:6068254 >>> objs_freed :5981076 >>> >>> Signed-off-by: Yang Shi > > I have no objection to adding one more tracking count. Thanks. Yang > > Cheers, > Longman >