From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 705E23DC4C9 for ; Tue, 21 Jul 2026 14:36:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784644583; cv=none; b=aoC1+IqhM5SHlyLCrUNWBPR+1uCKIBW38DCntU8KBXBUAwObacgXRgFiYG+uhLduXLMCZmV4CwcBiHDKATES096hDwI5ury6EYmXWtRTM7MwEzFKkY5qGsCofVTPf0R/VgpPiJOMOBO1fd2sxNwTII/czMYdIPqf/ZFkGIi1H2U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784644583; c=relaxed/simple; bh=OoHd7TmScpK4s9XFIUK4kzLosuDrHHYWMcyrjPULoK4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=TmBPBzz54X+Bq0YMPyc7xMAdqb38RFEDZJcdrrGE+SsIVhg6Jj2F7Ys5gW3rLoB8/DkRQpZmN29M1ddaomFa9xJOndUUUgCJYWpWXxqAPwGV2KafabF1xO33JJlHWP/sBIAVZMHah9HwNh1fAkyM01Tbkz50hrPdkSccm5Z4jyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Z96bWBdg; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Z96bWBdg" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784644574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=duDm2gflqWgjjtEl7oS0jFoAvjrKVH+EAkTNtAgJZ88=; b=Z96bWBdgbvO4x7jen0eD5hd7xJ0w8HgwHX7k6r8kOzu6I76z7/m93pya8vG0iyaPcS8+Ru 8S0b4QCNQkTOBoZ2K9/SENUFNbstVSCotXnEuMZ0d1LaUurkFQrvtKy+y45OM4FInpiFBh 7ho0zVuybuuAz/uWHivRSl8BteWYwbo= From: Lance Yang To: pmladek@suse.com, atomlin@atomlin.com Cc: akpm@linux-foundation.org, mhiramat@kernel.org, linux-kernel@vger.kernel.org, david.laight.linux@gmail.com, neelx@suse.com, sean@ashe.io, chjohnst@gmail.com, steve@abita.co, mproche@gmail.com, nick.lange@gmail.com, Lance Yang Subject: Re: [PATCH v6] hung_task: Deduplicate identical hang reports using explicit blocker tracking Date: Tue, 21 Jul 2026 22:35:59 +0800 Message-Id: <20260721143559.26594-1-lance.yang@linux.dev> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Tue, Jul 21, 2026 at 03:28:48PM +0200, Petr Mladek wrote: >On Tue 2026-07-21 13:08:32, Lance Yang wrote: >> >> On Sun, Jul 19, 2026 at 12:13:05PM -0400, Aaron Tomlin wrote: [...] >> >> Sorry for the late reply. > >Don't worry. IMHO, a reply within one week is perfectly >fine. Sometimes even this is not possible. Cheers! >> Still, v6 looks far too complicated ... and touches too much core code >> for the problem you're trying to address ... > >I agree that it looks too complicated. I see several problems: > > 1. Many changes are added in a single patch. I suggest to split > it next time into more patches and add the features from > the most important one, ... > > 2. The code seems to be a bit over-engineered. There are too many > variables hung_task_blockers_count, hung_task_has_active, > warnings_decremented, skip_show_task, scan_completed, > did_report, seen_blockers_mask, ... I believe that it might > be done an easier way. > > 3. Too much spaghetti code is added to the already large > check_hung_uninterruptible_tasks() function. It might look > better when the detection of the duplicated task is handled > in a separate function, ... v6 kinda snowballed :) Way too much state for what it buys us :) > >> Looked at this again ... Petr's earlier breakdown[1] makes sense. Both >> problems are real: >> >> " >> I would split this into two problems: >> >> 1. A single lock contention might trigger hung_report for many tasks >> waiting for the same lock. It bloats the kernel log and messages >> might even get lost. >> >> 2. The number of printed backtraces can be reduced by a global limit. >> But the limit silences the hung task detector and system >> administrators are blind once the limit is reached. >> " >> >> IMO, that's the tradeoff: keep log noise down without leaving users >> blind for good once budget runs out ... >> >> Still not sold on dedup, though. Sure, duplicate reports happen, but how >> often, really? Doesn't seem common enough to need this much code :) >> >> If we really want to handle this in kernel, how about a simple mode >> switch for hung_task_warnings? >> >> 0 = keep the current global budget >> 1 = allow up to hung_task_warnings reports in each scan > >Honestly, I do not think that this is the right way to go. The more I think >about it, the more I believe that the global budget is simply wrong. > >IMHO, we should do the following: > >1. Reset the global budget when the situation is resolved and > there is no hung task any longer. > >2. The global budget should limit only printing all the details, > especially backtraces. We should always print at least > the task name, ... Yeah, sounds better than another mode. Slight semantic change, but looks fine to me. >3. We could prevent printing the same process again and again > by adding "hung_task_reported" into struct task_struct. > > But then we should print some summary about how many hung tasks > were found in the last round at least. So that we know that > the problem persists. > > This should still be rather easy. But I am not sure if it is > worth it. With 1 and 2 in place, don't think this is needed anymore ;) >4. We could add the filtering of the duplicated backtraces. But > it has to be handled by some helper function. > > It looks like to most complicated part. I would personally skip > it for now. We could always add it later when the above proposed > changes are not enough to tune the kernel.hung_task_warnings > value in the real life. And blocker dedup gets even messier. Haven't seen a simple way to do that. Happy to skip it :D > > >I tried to implement the 1st and 2nd change using gemini just to >see how it would look. And it looks good to me: I really like this approach :) Hope v7 sticks to these two changes; think that's all we need :) [...] Cheers, Lance