From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753074AbdK1A3C (ORCPT ); Mon, 27 Nov 2017 19:29:02 -0500 Received: from out0-199.mail.aliyun.com ([140.205.0.199]:53745 "EHLO out0-199.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751751AbdK1A3B (ORCPT ); Mon, 27 Nov 2017 19:29:01 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03302;MF=yang.s@alibaba-inc.com;NM=1;PH=DS;RN=3;SR=0;TI=SMTPD_---.9Wdc9HF_1511828924; Subject: Re: [RFC PATCH 2/2] lib: debugobjects: touch watchdog to avoid softlockup when !CONFIG_PREEMPT To: Waiman Long , tglx@linutronix.de Cc: linux-kernel@vger.kernel.org References: <1510947833-116482-1-git-send-email-yang.s@alibaba-inc.com> <1510947833-116482-2-git-send-email-yang.s@alibaba-inc.com> <553877ed-843e-a59d-3a76-2e90ce192ab1@alibaba-inc.com> <1a6f92f5-2c12-1276-916b-fd2848899e5c@redhat.com> From: "Yang Shi" Message-ID: Date: Tue, 28 Nov 2017 08:28:43 +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: 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 11:36 AM, Waiman Long wrote: > On 11/27/2017 01:52 PM, Yang Shi wrote: >> >> >> On 11/27/17 10:18 AM, Waiman Long wrote: >>> On 11/27/2017 12:54 PM, Yang Shi wrote: >>>> Hi Waiman, >>>> >>>> The second patch of this series. >>>> >>>> Thanks, >>>> Yang >>>> >>>> >>>> On 11/17/17 11:43 AM, Yang Shi wrote: >>>>> There are nested loops on debug objects free path, sometimes it may >>>>> take >>>>> over hundred thousands of loops, then cause soft lockup with >>>>> !CONFIG_PREEMPT >>>>> occasionally, like below: >>>>> >>>>> ... >>>>> >>>>> The code path might be called in either atomic or non-atomic context, >>>>> so touching softlockup watchdog instead of calling cond_resched() >>>>> which >>>>> might fall asleep. However, it is unnecessary to touch the watchdog >>>>> every loop, so just touch the watchdog at every 10000 (best estimate) >>>>> loops. >>>>> >>>>> Signed-off-by: Yang Shi >>> >>> I do have some concern about suppressing the soft lockup warning >>> entirely. If the system feels unresponsive for a certain period of time >>> (e.g. 22s), most users would like to know what is going on. It can be a >>> custom message with less scary warning. Alternatively, some opt-out >> >> I'm not sure if it is necessary for debug code since the >> unresponsiveness is introduced by debug config and is expected >> somehow, so the user is supposed to know what they are doing, and it >> sounds preferred to disregard the soft lockup message reported by >> object debug for the most time. >> > > Yes, it may be normal to cause the soft lockup while running some kind > of stress tests. However, it isn't normal for a real user application to > cause the lockup on a debug kernel. That is why I am suggesting some > kind of opt-out mechanism so that one can turn off the soft lockup > warning for stress testing. Yes, I just saw such lockup when running some stress test, i.e. stress-ng. > >> We do have some other examples which suppress soft lockup completely >> in kernel, i.e. kdb debug, printing some verbose debug or error >> message, some slow driver code, etc. >> >>> mechanism can be added to explicitly disable soft lookup warning for >>> debugobjs is OK as long as it is not the default. >> If we really want to some opt-out, we should be able to add a proc >> knob to disable soft lockup as the patch does, but not default. If >> this is too overkilling, we may just add some comment in the Kconfig >> help text to tell users the side effect. > > You may add a new debugfs file under the debug_objects sub-directory for > suppressing the soft lockup message. OK, will add a knob in v2. Thanks, Yang > > Cheers, > Longman >