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 6A1EFC433F5 for ; Tue, 14 Dec 2021 11:43:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233663AbhLNLnA (ORCPT ); Tue, 14 Dec 2021 06:43:00 -0500 Received: from gentwo.de ([161.97.139.209]:58832 "EHLO gentwo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233644AbhLNLm7 (ORCPT ); Tue, 14 Dec 2021 06:42:59 -0500 Received: by gentwo.de (Postfix, from userid 1001) id 1C483B0024C; Tue, 14 Dec 2021 12:42:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by gentwo.de (Postfix) with ESMTP id 19CD9B00127; Tue, 14 Dec 2021 12:42:58 +0100 (CET) Date: Tue, 14 Dec 2021 12:42:58 +0100 (CET) From: Christoph Lameter X-X-Sender: cl@gentwo.de To: Marcelo Tosatti cc: Mel Gorman , Thomas Gleixner , Frederic Weisbecker , Christoph Lameter , Nicolas Saenz Julienne , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, nilal@redhat.com, linux-rt-users@vger.kernel.org, vbabka@suse.cz, ppandit@redhat.com Subject: Re: [PATCH v2 3/3] mm/page_alloc: Remotely drain per-cpu lists In-Reply-To: <20211214105823.GA53878@fuller.cnet> Message-ID: References: <20211103170512.2745765-1-nsaenzju@redhat.com> <20211103170512.2745765-4-nsaenzju@redhat.com> <20211203141306.GG3301@suse.de> <20211209174535.GA70283@fuller.cnet> <20211210105549.GJ3301@suse.de> <20211214105823.GA53878@fuller.cnet> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 14 Dec 2021, Marcelo Tosatti wrote: > > downside is that there will be a performance penalty if an application > > running on a NOHZ_FULL CPU is page allocator intensive for whatever > > reason. However, I guess this is unlikely because if there was a lot > > of kernel activity for a NOHZ_FULL CPU, the vmstat shepherd would also > > cause interference. > > Yes, it does, and its being fixed: > > https://lkml.org/lkml/2021/12/8/663 > > Honestly i am not sure whether the association between a nohz_full CPU > and "should be mostly in userspace" is desired. The RCU solution > would be more generic. As Nicolas mentioned, for the usecases in > questions, either solution is OK. > > Thomas, Frederic, Christoph, do you have any opinion on this ? Applications running would ideally have no performance penalty and there is no issue with kernel activity unless the application is in its special low latency loop. NOHZ is currently only activated after spinning in that loop for 2 seconds or so. Would be best to be able to trigger that manually somehow. And I would prefer to be able to run the whole system as NOHZ and have the ability to selectively enable the quiet mode if a process requires it for its processing.