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=-8.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 88A90C64E7B for ; Wed, 2 Dec 2020 15:29:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CEECE20B1F for ; Wed, 2 Dec 2020 15:29:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEECE20B1F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E28776B005D; Wed, 2 Dec 2020 10:29:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD8878D0002; Wed, 2 Dec 2020 10:29:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C77038D0001; Wed, 2 Dec 2020 10:29:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id AFC186B005D for ; Wed, 2 Dec 2020 10:29:42 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 64E52181AEF23 for ; Wed, 2 Dec 2020 15:29:42 +0000 (UTC) X-FDA: 77548727004.16.drum47_6010cbc273b4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id 518DE100E693D for ; Wed, 2 Dec 2020 15:29:31 +0000 (UTC) X-HE-Tag: drum47_6010cbc273b4 X-Filterd-Recvd-Size: 4817 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Dec 2020 15:29:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1606922970; 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=xbUFaA20eGOwgokifaQmAZ7/Dr89OYx1nMCuxfxYGro=; b=N9GN8us37dmPCBFv0Gb9ZGf20S8Uv8/CSFK8NTnTU7YFdCZhs0drOmx7RdxIInFPlrNwqd gn+fy56cSCUsYPn0SqGHBzHMlomQmo+sA56HNIjuknoV/aZoRYI3pATOjd07RZniOjj4oV vKZEL31jjb8KZo+O3jjyxSp2h4lSCtQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-546-4Eh-jSz6NFS7j0iVjt5Fvg-1; Wed, 02 Dec 2020 10:29:28 -0500 X-MC-Unique: 4Eh-jSz6NFS7j0iVjt5Fvg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DBED318C9F44; Wed, 2 Dec 2020 15:29:26 +0000 (UTC) Received: from fuller.cnet (ovpn-112-4.gru2.redhat.com [10.97.112.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 98FDC5D9CA; Wed, 2 Dec 2020 15:29:26 +0000 (UTC) Received: by fuller.cnet (Postfix, from userid 1000) id 253B64172ED8; Wed, 2 Dec 2020 09:43:59 -0300 (-03) Date: Wed, 2 Dec 2020 09:43:59 -0300 From: Marcelo Tosatti To: Christoph Lameter Cc: Matthew Wilcox , linux-mm@kvack.org, Andrew Morton , Alex Belits , Phil Auld , Thomas Gleixner , Frederic Weisbecker , Peter Zijlstra Subject: Re: [PATCH] mm: introduce sysctl file to flush per-cpu vmstat statistics Message-ID: <20201202124359.GA80090@fuller.cnet> References: <20201117162805.GA274911@fuller.cnet> <20201117180356.GT29991@casper.infradead.org> <20201117202317.GA282679@fuller.cnet> <20201127154845.GA9100@fuller.cnet> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=mtosatti@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Mon, Nov 30, 2020 at 09:31:47AM +0000, Christoph Lameter wrote: > On Fri, 27 Nov 2020, Marcelo Tosatti wrote: > > > Decided to switch to prctl interface, and then it starts > > to become similar to "task mode isolation" patchset API. > > Right I think that was a good approach. > > > In addition to quiescing pending activities on the CPU, it would > > also be useful to assign a per-task attribute (which is then assigned > > to a per-CPU attribute), indicating whether that CPU is running > > an isolated task or not. > > Sounds good but what would this do? Give a warning like the isolation > patchset? Could be. Or disallow certain operations such as CPU hotplug, ring buffer resize, etc. > > This per-CPU attribute can be used to, for example, return -EBUSY > > from ring_buffer_resize() (or any other IPI generating activity > > which can return an error to userspace). > > Yes good. > > > So rather than: > > > > prctl(PR_QUIESCE_CPU) (current interface, similar to > > initial message on the thread but with prctl rather than > > sysfs) > > > > To be called before real time loop, one would have: > > > > prctl(PR_SET_TASK_ISOLATION, ISOLATION_ENABLE) [1] > > real time loop > > prctl(PR_SET_TASK_ISOLATION, ISOLATION_DISABLE) > > > > (with the attribute also being cleared on task exit). > > > > The general description would be: > > > > "Set task isolated mode for a given task, returning an error > > if the task is not pinned to a single CPU. > > > > In this mode, the kernel will avoid interruptions to isolated > > CPUs when possible." > > > > Any objections against such an interface ? > > Maybe do both like in the isolation patchset? > > Often code can tolerate a few interruptions (in some code branches > regular syscalls may be needed) but one wants the thread to be > as quiet as possible. Yes, thanks.