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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73FE3C6369E for ; Thu, 3 Dec 2020 03:17:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8157221FB for ; Thu, 3 Dec 2020 03:17:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8157221FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CC9066B005C; Wed, 2 Dec 2020 22:17:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C76DA6B005D; Wed, 2 Dec 2020 22:17:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B65296B0068; Wed, 2 Dec 2020 22:17:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 9C95F6B005C for ; Wed, 2 Dec 2020 22:17:40 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 57BD9181AEF23 for ; Thu, 3 Dec 2020 03:17:40 +0000 (UTC) X-FDA: 77550511080.11.base97_3515b4d273b8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 2D00D180F8B80 for ; Thu, 3 Dec 2020 03:17:40 +0000 (UTC) X-HE-Tag: base97_3515b4d273b8 X-Filterd-Recvd-Size: 6548 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 03:17:39 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1606965457; 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: in-reply-to:in-reply-to:references:references; bh=M/y23asZh1+Vw/Mi3RWB4fcYmhyiP292FextTwy9TjA=; b=lV7gRJMlT0doQes4DoNTUxlLao1T1JqvX14WAIIj8sZYbvjEBLF9qAWxF7gHSTRFE/kebC 2iWLqVGlYqzsAoQsZ+fHa14FGzyCGGS4rcth3vhAP6Jcfo+HNSGXRNOzl6DY56qFkTAhRU KmWYItQBYylCIDs7/y2eeVGNDR1aLBGsNaK5HG6P8v0GhjP5efNAv/OZvpjIVJOH5m8ZF5 PxoHKDC7BeKCcsY6BS10JmwO5J7qk6MNWGJAFpMuZH4WTJ/u8aAQ34HxN5hCTTazzoYEHp 9i4cd11ndgMoXL9BK/eLnIzpzExsrh55yaqhAbgNYf7jDjbfNO7+Ipr3t2JNzA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1606965457; 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: in-reply-to:in-reply-to:references:references; bh=M/y23asZh1+Vw/Mi3RWB4fcYmhyiP292FextTwy9TjA=; b=eVbVaZP0hvSxcowjf8YCQkL4jIc3YC0eRV0gbP29bP3phsPsA7qkJ3z42lcYpPQOWzG/kk waiRlT+livMvvhAA== To: Christoph Lameter Cc: Marcelo Tosatti , Matthew Wilcox , linux-mm@kvack.org, Andrew Morton , Alex Belits , Phil Auld , Frederic Weisbecker , Peter Zijlstra Subject: Re: [PATCH] mm: introduce sysctl file to flush per-cpu vmstat statistics In-Reply-To: References: <20201117162805.GA274911@fuller.cnet> <20201117180356.GT29991@casper.infradead.org> <20201117202317.GA282679@fuller.cnet> <20201127154845.GA9100@fuller.cnet> <87h7p4dwus.fsf@nanos.tec.linutronix.de> Date: Thu, 03 Dec 2020 04:17:36 +0100 Message-ID: <87v9djd1db.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain 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: On Wed, Dec 02 2020 at 17:43, Christoph Lameter wrote: > On Wed, 2 Dec 2020, Thomas Gleixner wrote: > >> prctl() is the right thing to do. > > Ok great consensus on that one. That's the easy part :) >> The current CPU isolation is a best effort approach and I agree that for >> more strict isolation modes we need to be able to enforce that and hunt >> down offenders and think about them one by one. > > There are two apprahces actually to make the OS quiet. One is the best > effort approach which is more like the current NOHZ one with additional > actions to flush things. The other is the strict approach were one wants a > guarantee that the OS does not do anything at all. And here the consensus stops again :) The point is that between the relaxed best effort / heuristics based scenario and the 'user space task asks for absolute silence' scenario is a huge difference: Is this really a black and white decision? Definitely not. That would be again an imposed policy decision which is wrong to begin with. We burnt ourself with that over and over so can we please and if it's just for this particular problem learn from history? The kernel provides mechanisms but does not impose policies unless there is no other choice. And as we know that there are quite some shades of grey, there is lots of choice and we need to come up with solutions for delegating the policy decision to the user/admin and not just provide a off/on knob. This 'isolate either perhaps or everything' appraoch is just wrong. The partisan thinking is obviously popular in the US, but it has no business in making technically sensible desicions. >> So you say some code can tolerate a few interrupts, then comes Alex and >> says 'no disturbance' at all. > > Yes that is the current NOHZ approach. You switch it on and after the OS > detects are polling loop it will quiet things down. Instead of detecting > it we are actively telling the OS to quiet down now. Kinda. We want to provide mechanisms to quiet certain aspects of the OS and to enable enforcement of that, but again, that's not on/off it has to be configurable / selectable. Again: I fundamentaly disagree with the proposed task isolation patches approach as they leave no choice at all. There is a reasonable middle ground where an application is willing to pay the price (delay) until the reqested quiescing has taken place in order to run undisturbed (hint: cache ...) and also is willing to take the addtional overhead of an occacional syscall in the slow path without tripping some OS imposed isolation safe guard. Aside of that such a granular approach does not necessarily require the application to be aware of it. If the admin knows the computational pattern of the application, e.g. 1 read_data_set() <- involving syscalls/OS obviously 2 compute_set() <- let me alone 3 save_data_set() <- involving syscalls/OS obviously repeat the above... then it's at his discretion to decide to inflict a particular isolation set on the task which is obviously ineffective while doing #1 and #3 but might provide the so desired 0.9% boost for compute_set() which dominates the judgement. That's what we need to think about and once we figured out how to do that it gives Marcelo the mechanism to solve his 'run virt undisturbed by vmstat or whatever' problem and it allows Alex to build his stuff on it. Summary: The problem to be solved cannot be restricted to self_defined_important_task(OWN_WORLD); Policy is not a binary on/off problem. It's manifold across all levels of the stack and only a kernel problem when it comes down to the last line of defence. Up to the point where the kernel puts the line of last defence, policy is defined by the user/admin via mechanims provided by the kernel. Emphasis on "mechanims provided by the kernel", aka. user API. Just in case, I hope that I don't have to explain what level of scrunity and thought this requires. Thanks, tglx