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 4E32EC77B72 for ; Thu, 20 Apr 2023 08:40:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234308AbjDTIkc (ORCPT ); Thu, 20 Apr 2023 04:40:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229543AbjDTIk3 (ORCPT ); Thu, 20 Apr 2023 04:40:29 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C398340C7 for ; Thu, 20 Apr 2023 01:40:27 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id DE9A72188F; Thu, 20 Apr 2023 08:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681980025; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=psUcnuY/w561sLF9FEzotMA5NMwI4obQ8dTonjhOYWQ=; b=vEM1P4IF7e2R2tj9sfsDmTf1Y8+LO0GGYN9OH9KqScwkYgNEmoqUVXvbhT8G14JIQ/6Tie gbBTccs8gMqtmQ134Ulr4wrkWDSyMRxBCaxrzXYYSBsPmwKbPnNa5TbyOpFZLaqI2msPJj FFZQ3ftw9NgMa0fPe4RmYqzKyNs/8Uw= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id BE2E61333C; Thu, 20 Apr 2023 08:40:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 7lwYLHn6QGRBdQAAMHmgww (envelope-from ); Thu, 20 Apr 2023 08:40:25 +0000 Date: Thu, 20 Apr 2023 10:40:25 +0200 From: Michal Hocko To: Marcelo Tosatti Cc: Frederic Weisbecker , Andrew Morton , Christoph Lameter , Aaron Tomlin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Russell King , Huacai Chen , Heiko Carstens , x86@kernel.org, Vlastimil Babka Subject: Re: [PATCH v7 00/13] fold per-CPU vmstats remotely Message-ID: References: <20230320180332.102837832@redhat.com> <20230418150200.027528c155853fea8e4f58b2@linux-foundation.org> 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-kernel@vger.kernel.org On Wed 19-04-23 13:35:12, Marcelo Tosatti wrote: [...] > This is a burden for application writers and for system configuration. Yes. And I find it reasonable to expect that burden put there as there are non-trivial requirements for those workloads anyway. It is not out-of-the-box thing, right? > Or it could be done automatically (from outside of the application). > Which is what is described and implemented here: > > https://lore.kernel.org/lkml/20220204173537.429902988@fedora.localdomain/ > > "Task isolation is divided in two main steps: configuration and > activation. > > Each step can be performed by an external tool or the latency > sensitive application itself. util-linux contains the "chisol" tool > for this purpose." I cannot say I would be a fan of prctl interfaces in general but I do agree with the overal idea to forcing a quiescent state on a set of CPUs. > But not only that, the second thing is: > > "> Another important point is this: if an application dirties > > its own per-CPU vmstat cache, while performing a system call, > > Or while handling a VM-exit from a vCPU. Do you have any specific examples on this? > This are, in my mind, sufficient reasons to discard the "flush per-cpu > caches" idea. This is also why i chose to abandon the prctrl interface > patchset. > > > and a vmstat sync event is triggered on a different CPU, you'd have to: > > > > 1) Wait for that CPU to return to userspace and sync its stats > > (unfeasible). > > > > 2) Queue work to execute on that CPU (undesirable, as that causes > > an interruption). > > > > 3) Remotely sync the vmstat for that CPU." > > So the only option is to remotely sync vmstat for the CPU > (unless you have a better suggestion). `echo 1 > /proc/sys/vm/stat_refresh' achieves essentially the same without any kernel changes. But let me repeat, this is not just about vmstats. Just have a look at other queue_work_on users. You do not want to handy pick each and every one and do so in the future as well. -- Michal Hocko SUSE Labs