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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 506EAC77B73 for ; Wed, 24 May 2023 12:52:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB777900003; Wed, 24 May 2023 08:52:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C716B900002; Wed, 24 May 2023 08:52:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2F3D900003; Wed, 24 May 2023 08:52:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A32FD900002 for ; Wed, 24 May 2023 08:52:01 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 73DD0408E8 for ; Wed, 24 May 2023 12:52:01 +0000 (UTC) X-FDA: 80825136042.12.DDD2E44 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf14.hostedemail.com (Postfix) with ESMTP id 265AE100009 for ; Wed, 24 May 2023 12:51:57 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=m7WrSXyU; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684932718; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=N/gy0k3e794wotWy75Qhs+8/ZV46Dj45SDKUp9pn8Rc=; b=KapNH+cO+vfw1PkD09L3Ktqe6oKg2k+xJuHRhs898Z05D4YhtNnduZ7o+jLGjwSmJNTYEC H4vwzMzzB9OThjMDIoxuf/98+QG/AnJgS24O1AEQB03fTnBAGS16kJZYCMjmFXW5AJae4T HxNJRc2nwWRNi15B0tpI/XtkM67p4S0= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=m7WrSXyU; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf14.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684932718; a=rsa-sha256; cv=none; b=0hq81Xp5v6NvjS4aEW41nGtHHOFeIMMLVy0WSxmfhOKx5OEb3mtRQZoBxTUIgOD89oQYtQ k04QOd5npQmkjKQXcVUn/ZoPPT1UIwNXPt4TcwZAjp5K/LoqGskbtrDQZmYLRVnSzfPhND 7XGwq+/KDHcIJh4ck4C9xiXi4ez+xS0= 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 AD4A0221F4; Wed, 24 May 2023 12:51:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1684932716; 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=N/gy0k3e794wotWy75Qhs+8/ZV46Dj45SDKUp9pn8Rc=; b=m7WrSXyUialsi0sAVP4s1PWnGSWrhOkeY+NmvcKtrk3dY24FjdIM6DrsG3xbL8RLEUnTNf sKKuvWguR3MUViMwdNUOQtYriJaKmyoJdGQTwOX4rR99v2jtl5c9HGo8aJNeeC/H2GTNPp AAOw4xQDbkYFmV0iEIQKNtDZGgUeWf4= 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 8FD88133E6; Wed, 24 May 2023 12:51:56 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id a+zlIGwIbmQVdAAAMHmgww (envelope-from ); Wed, 24 May 2023 12:51:56 +0000 Date: Wed, 24 May 2023 14:51:55 +0200 From: Michal Hocko To: Marcelo Tosatti Cc: Christoph Lameter , Aaron Tomlin , Frederic Weisbecker , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Russell King , Huacai Chen , Heiko Carstens , x86@kernel.org, Vlastimil Babka Subject: Re: [PATCH v8 00/13] fold per-CPU vmstats remotely Message-ID: References: <20230515180015.016409657@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230515180015.016409657@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 265AE100009 X-Stat-Signature: j54zzk3bd1m669imdm53a8skhmgtcwjt X-HE-Tag: 1684932717-774886 X-HE-Meta: U2FsdGVkX1/nsjPTYUgRTZui6Nib3OLQQ74NVxo4S2B1GUJg81Oc9cULw0+WykUTEg0FMnGacLs1RapMpTzfXcb4ya+oFwdC5+SJxcv63MO+GwgoOZIvdiyTAj9I2x2t2qPy7uanREjBRtA+T4gLWZKPezyRsAa384yNrFtLXd8qSRGLYJmeRvXt5yqlXrTn6ybAyBVV54zTGgi0ZifAY8XtdsW522Ko3S/aF1QMG3Glcze+ON7cOoA2MydffbUVjuD9uo7mm0pP9DsY/u2XIgPEHJe4fhrB8er+GLp8UNn6312a3MTg1JteThRC+KBlc5HaM3N5ipMi8fm5AqzPGPYk9Tv3mfOPm7H6AJyjnEqSLid7sFg0srTLOyx+uwtc1Kq5P0hXZ9jfmMAKU3vyFeQC+HP6+4LsCkjlNh0sVrABUlG21SzOMISzvrNREnadV1/BJy39xxwB4RRJtFQWlUTYsMIWmdrcxY3kJ4TKUA/Cl3+WIZXl/AP3fhAHN7/9xKLXPDOOOcruswxthT7dcYELmMYdOvJTl+gH5JKmAOuYFJ70V/XxrEvPXB958zzGlMbFM8Fsn2bIZHbgoYpLivsk71VcCWwLx4ZeDAbGe5TGLAdPDj9tOUCs6clw9a5i5R9Dn0oLewxMIDcP9ujzW1k/D0hwZsMWrB31yoyLz6QA596+x/hiizeTzh19wMaRDtJY03DmxgQvZbJXPp+vYBtMYocPzL7pKm11qCAtOm3KNOoede9JqszdMtFKMKx0obScx+lu4BJeJfwxRLreKicdzxgVjrpNNq+ZDZfD9j7adlp4fQnmRT5Txs0fbAYG4vdpBUTMuEFdkmmNR+K1+vx5sGqA91dQ5hgxiovrrueC7gj0LN/D8149PulDCEJ22GYjFd5PgABYQij8Hd6p8o65Qj008c2XZODsZl7zo01NawkwgTtSWUv0Y/hu2MxDTFCZuJBPjuV8KiPUx3u XhbRa48F z8rMLJu8AzPRy4efI0DIAUQ+6Bk+Znmi5k5JaF77sjW05jpSfhQjatKZO28uGipdEmeAreyquB8IwwECDJ7PseOGdvMpP/i1/hljh2vhXQKA5A+RdIo6e6X344iAUieBaw1LwfbdhK7BThwDDxKN4He79fQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: [Sorry for a late response but I was conferencing last two weeks and now catching up] On Mon 15-05-23 15:00:15, Marcelo Tosatti wrote: [...] > v8 > - Add summary of discussion on -v7 to cover letter Thanks this is very useful! This helps to frame the further discussion. I believe the most important question to answer is this in fact > I think what needs to be done is to avoid new queue_work_on() > users from being introduced in the tree (the number of > existing ones is finite and can therefore be fixed). > > Agree with the criticism here, however, i can't see other > options than the following: > > 1) Given an activity, which contains a sequence of instructions > to execute on a CPU, to change the algorithm > to execute that code remotely (therefore avoid interrupting a CPU), > or to avoid the interruption somehow (which must be dealt with > on a case-by-case basis). > > 2) To block that activity from happening in the first place, > for the sites where it can be blocked (that return errors to > userspace, for example). > > 3) Completly isolate the CPU from the kernel (off-line it). I agree that a reliable cpu isolation implementation needs to address queue_work_on problem. And it has to do that _realiably_. This cannot by achieved by an endless whack-a-mole and chasing each new instance. There must be a more systematic approach. One way would be to change the semantic of schedule_work_on and fail call for an isolated CPU. The caller would have a way to fallback and handle the operation by other means. E.g. vmstat could simply ignore folding pcp data because an imprecision shouldn't really matter. Other callers might chose to do the operation remotely. This is a lot of work, no doubt about that, but it is a long term maintainable solution that doesn't give you new surprises with any new released kernel. There are likely other remote interfaces that would need to follow that scheme. If the cpu isolation is not planned to be worth that time investment then I do not think it is also worth reducing a highly optimized vmstat code. These stats are invoked from many hot paths and per-cpu implementation has been optimized for that case. If your workload would like to avoid that as disturbing then you already have a quiet_vmstat precedence so find a way how to use it for your workload instead. -- Michal Hocko SUSE Labs