From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E315C77B7C for ; Sun, 7 May 2023 17:12:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231535AbjEGRMn (ORCPT ); Sun, 7 May 2023 13:12:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229948AbjEGRMm (ORCPT ); Sun, 7 May 2023 13:12:42 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 16455100D9; Sun, 7 May 2023 10:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1683479559; x=1715015559; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=xadsDlIqSLYDH8jAUQJ+rU/bh9AyzgsU04VnNDkPNZk=; b=UwySByN+YkfSAk6pK1Oydz5lI4I53iHIoPty4SiLewuSURi7QhMFP7wK XlMjkw+mt7iIFUjnxMwqa48Y5uDSIq88PgE9Vq79VtBuqOEwN5emMtWUE LBYycJ5thV3HhRleCYnYlXemCbyK29p4vtDPBdAzvXahdS+Z+CS1yyIz4 u+Ts4o4fO7fUA3AE9oewIkQohzyBmTmBZsz8G5cSs+uFXoqJ6Ok87Gmq1 cmcGE6Mw8VdCiZF3kf6zTJiHo7gF6Rjjv3yweMe+QLT5WeO3uMYC9BDRT D3A5MB7UwnXYQgYzwTuu+V2tLi1WmVKEc18LwNvZJQZVUDarlbCrQrZVv Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10703"; a="333933231" X-IronPort-AV: E=Sophos;i="5.99,257,1677571200"; d="scan'208";a="333933231" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2023 10:12:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10703"; a="842466547" X-IronPort-AV: E=Sophos;i="5.99,257,1677571200"; d="scan'208";a="842466547" Received: from tassilo.jf.intel.com (HELO tassilo) ([10.54.38.190]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 May 2023 10:12:37 -0700 Date: Sun, 7 May 2023 10:12:29 -0700 From: Andi Kleen To: Doug Anderson Cc: Ian Rogers , ravi.v.shankar@intel.com, ricardo.neri@intel.com, Stephane Eranian , Petr Mladek , Andrew Morton , Lecopzer Chen , Daniel Thompson , Stephen Boyd , Chen-Yu Tsai , linux-arm-kernel@lists.infradead.org, kgdb-bugreport@lists.sourceforge.net, Marc Zyngier , linux-perf-users@vger.kernel.org, Mark Rutland , Masayoshi Mizuma , Will Deacon , ito-yuichi@fujitsu.com, Sumit Garg , Catalin Marinas , Colin Cross , Matthias Kaehlcke , Guenter Roeck , Tzung-Bi Shih , Alexander Potapenko , AngeloGioacchino Del Regno , Dan Williams , Geert Uytterhoeven , Ingo Molnar , John Ogness , Josh Poimboeuf , Juergen Gross , Kees Cook , Laurent Dufour , Liam Howlett , Marco Elver , Matthias Brugger , Michael Ellerman , Miguel Ojeda , Nathan Chancellor , Nick Desaulniers , "Paul E. McKenney" , Peter Zijlstra , Randy Dunlap , Rasmus Villemoes , Sami Tolvanen , Stefano Stabellini , Vlastimil Babka , Zhaoyang Huang , Zhen Lei , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH] hardlockup: detect hard lockups using secondary (buddy) cpus Message-ID: References: <20230421155255.1.I6bf789d21d0c3d75d382e7e51a804a7a51315f2c@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org On Mon, Apr 24, 2023 at 08:23:59AM -0700, Doug Anderson wrote: > HPET system seems to have a single CPU in charge of processing the > main NMI and then that single CPU is in charge of checking all the > others. If that single CPU goes out to lunch then the system couldn't > detect hard lockups. > > In any case, I'm happy to let others debate about the HPET system. For > now, I'll take my action items to be: We don't really seem to make any progress on the HPET series, so even if it is better in some way a series that is never merged is always worse than one that is. My experience is that cases where everything locks up are very rare. I suspect as long as we cover the garden variety single CPU lockup case well it is likely very diminishing returns to handle more complex cases. So whatever gets the job done is fine. Yes freeing the Perfmon resources is big advantage of either. -Andi