From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754445AbeAQRAO convert rfc822-to-8bit (ORCPT ); Wed, 17 Jan 2018 12:00:14 -0500 Received: from mout.gmx.net ([212.227.17.22]:52256 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754086AbeAQRAM (ORCPT ); Wed, 17 Jan 2018 12:00:12 -0500 Message-ID: <1516208339.31983.58.camel@gmx.de> Subject: Re: [GIT PULL] isolation: 1Hz residual tick offloading v3 From: Mike Galbraith To: Christopher Lameter Cc: Frederic Weisbecker , Luiz Capitulino , Ingo Molnar , LKML , Peter Zijlstra , Chris Metcalf , Thomas Gleixner , "Paul E . McKenney" , Wanpeng Li , Rik van Riel Date: Wed, 17 Jan 2018 17:58:59 +0100 In-Reply-To: References: <1515039937-367-1-git-send-email-frederic@kernel.org> <20180112141813.32dcc84d@redhat.com> <20180116154055.GA27042@lerouge> <1516125498.6599.23.camel@gmx.de> <1516204793.31983.39.camel@gmx.de> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K0:qQjs6r2sT213V3nPeCUBPr7p6uSHyi2yXrAS2LtGAFwG/tgLj9A L6RnZQmlLEIer9iP+jouuCp+GFr7eYUDplKs8Mq1JntCKEqdIu6eNZTedGZAeUqx9Qeh27D JrEMwwC11o9oGBYz9+Kg83iPymUwCbF11gQHzRS9MUuAsBnmt1drVdJIH+gw1W1pcnci0+1 863vEZ72SMbEjKXgAaUKg== X-UI-Out-Filterresults: notjunk:1;V01:K0:MNWFcCOkSlU=:WMzSqV8aaXFvcy2wutgFJf 7Xatj7FVajMky9WvwXsQeAB1CeSxrPB4kQs6QHs0JEX5FpzizGRRwG2w8++TbTA3zKr2z0klo 6mPYiuqkt1HkI0PilfPs4Y7/gi12yOKv6De3bkOSe1P1gZsgxPEPBDJRbNlSt+TmAs9TjHWRP yRmkSnKPqbGvaTi5SRDIg3Cu6TutZGowSJSb4vrhVlRlPvmUNb4aOQk9g2k261v/zHVpxUaL3 /DUccZFg4BmDfd9VdF1AQOpq1IJNF/OUJiyZFTaabXNdl2C+3xQGB88SsS8t/WXccOZL10hIG xqx5i6E4eFT8ggfv0aeJVNgxGb98mtUufUUW8310orq8LwyOUj6hzkhFgTwmqPdzR0r61sCwY xuCPsA4DIFwEmDCKhMEgBm6z/hjTRcdc9SINPmQn8Jw/7clAKFQucKwpj2onvvdymcqp2bkFL xMcY3Dru1STQkDeMVUDUZM49To7z6QPbUbeKc2xdY0kTyaLJFr1vT5atxVR/DM8JGN7rPp0Un NEElUTPN3lqRBizz70Zav3PMGyHWzKKeHY3Gm3Vr2TbJJG3eiBNLSKRJJgHVGQDbh0ZT7QFyq dAevezW4pe6LXRxDzSD3iMKETCehxs+QiPcp0YkM2kiafmzrY8RCtTM0MMPoYLMFi/1+oiF2z t2Nv1aIGwcZS3P12JsRqVMhTDAqP+SYsdQUpG4L1X1SJh2fUgmf3TR0bJ1IQFQhUg4Lix4aVV M88GTzg//zYywJUdcBEfjEFJ3YlGJzvwelIL9ACjOImvHfGwBYBD1J7DrjCI8qi+EjEige7T4 qW/8vnKLlTOZ5l4WzjJd+oqcLHyEL2xys26AFs4xWNcHWixy7E= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-01-17 at 10:32 -0600, Christopher Lameter wrote: > On Wed, 17 Jan 2018, Mike Galbraith wrote: > > > Domain connectivity very much is a property of a set of CPUs, a rather > > important one, and one managed by cpusets.  NOHZ_FULL is a property of > > a set of cpus, thus a most excellent fit.  Other things are as well. > > Not sure to what domain refers to in this context. Scheduler domains, load balancing. > > > We have sets of cpus associated with affinity masks in the form of bitmaps > > > etc etc which is much more lightweight than having slug around the cgroup > > > overhead everywhere. > > > > What does everywhere mean, set creation time? > > You would need to create multiple cgroups to create what you want. Those > will "inherit" characteristics from higher levels etc etc. It gets > needlessly complicated and difficult to debug if something goes work. It's only as complicated as you make it.  What I create is dirt simple, an exclusive system set and an exclusive realtime set, both directly under root.  It doesn't get any simpler than that. > > > A simple bitmask is much better if you have to control detailed system > > > behavior for each core and are planning each processes role because you > > > need to make full use of the harware resources available. > > > > If you live in a static world, maybe. > > Why would that be restricted to a static world? Guess I misunderstood, unimportant. > > I like the flexibility of being able to configure on the fly.  One tiny > > example: for a high performance aircraft manufacturer, having military > > simulation background, I know that simulators frequently have to be > > ready to go at the drop of a hat, so I twiddled cpusets to let them > > flip their extra fancy video game (80 cores, real controls/avionics... > > "game over, insert one gold bar to continue" kind of fancy) from low > > power idle to full bore hard realtime with one poke to a cpuset file. > > > > Static may be fine for some, for others, dynamic is much better. > > The problem is that I may be flipping a flag in a cpuset to enable > something but some other cpuset somewhere in the complex hieracy does > something different that causes a conflict. That's what exclusive sets are for, zero set overlap.  It would be very difficult to both connect and disconnect scheduler domains :) > The directness to control is > lost. Instead there is the fog of complexity created by the cgroups that > have various plugins and whatnot. You don't have to use any of the other controllers, I don't, just tell systemthing to pretty please NOT co-mount controllers, and whatever to ensure it keeps its tentacles off of your toys, and you're fine. -Mike