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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 23783C433E0 for ; Thu, 14 Jan 2021 09:22:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8D8FF23A1D for ; Thu, 14 Jan 2021 09:22:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D8FF23A1D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DACD98D00CA; Thu, 14 Jan 2021 04:22:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5BEF8D008E; Thu, 14 Jan 2021 04:22:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C238F8D00CA; Thu, 14 Jan 2021 04:22:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0082.hostedemail.com [216.40.44.82]) by kanga.kvack.org (Postfix) with ESMTP id A9E818D008E for ; Thu, 14 Jan 2021 04:22:55 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 5CAA618200A01 for ; Thu, 14 Jan 2021 09:22:55 +0000 (UTC) X-FDA: 77703841110.11.wine45_4a0f0f027525 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 3FB78182009FA for ; Thu, 14 Jan 2021 09:22:55 +0000 (UTC) X-HE-Tag: wine45_4a0f0f027525 X-Filterd-Recvd-Size: 3252 Received: from gentwo.org (gentwo.org [3.19.106.255]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 09:22:54 +0000 (UTC) Received: by gentwo.org (Postfix, from userid 1002) id 5AB1C42153; Thu, 14 Jan 2021 09:22:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 5880142151; Thu, 14 Jan 2021 09:22:54 +0000 (UTC) Date: Thu, 14 Jan 2021 09:22:54 +0000 (UTC) From: Christoph Lameter X-X-Sender: cl@www.lameter.com To: Marcelo Tosatti cc: Alex Belits , "tglx@linutronix.de" , "pauld@redhat.com" , "linux-mm@kvack.org" , "frederic@kernel.org" , "willy@infradead.org" , "peterz@infradead.org" , "akpm@linux-foundation.org" , Juri Lelli , Daniel Bristot de Oliveira Subject: Re: [RFC] tentative prctl task isolation interface In-Reply-To: <20210113121544.GA16380@fuller.cnet> Message-ID: References: <20201117162805.GA274911@fuller.cnet> <20201117180356.GT29991@casper.infradead.org> <20201117202317.GA282679@fuller.cnet> <20201127154845.GA9100@fuller.cnet> <87h7p4dwus.fsf@nanos.tec.linutronix.de> <12ddb629555590cfd41db5b10854d95c1f154e24.camel@marvell.com> <20210113121544.GA16380@fuller.cnet> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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, 13 Jan 2021, Marcelo Tosatti wrote: > So as discussed, this is one possible prctl interface for > task isolation. > > Is this something that is desired? If not, what is the > proper way for the interface to be? Sure that sounds liek a good beginning but I guess we need some specificity on the features > +Task isolation CPU interface > +============================ How does one do a oneshot flush of OS activities? I.e. I have a polling loop over numerous shared and I/o devices in user space and I want to make sure that the system is quite before I enter the loop. In the loop itself some activities may require syscalls so they will potentialy cause the OS services such as timers to start again. When such an activities is complete another quiet down call can be issued. Could be implemented by setting a flag that does an action and then resets itself? Or the flag could be reset if a syscall that requires timers etc is used? Features that I think may be needed: F_ISOL_QUIESCE -> quiet down now but allow all OS activities. OS activites reset flag F_ISOL_BAREMETAL_HARD -> No OS interruptions. Fault on syscalls that require such actions in the future. F_ISOL_BAREMETAL_WARN -> Similar. Create a warning in the syslog when OS services require delayed processing etc but continue while resetting the flag.