linux-kernel - Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1516208339.31983.58.camel@gmx.de>
Date:   Wed, 17 Jan 2018 17:58:59 +0100
From:   Mike Galbraith <efault@....de>
To:     Christopher Lameter <cl@...ux.com>
Cc:     Frederic Weisbecker <frederic@...nel.org>,
        Luiz Capitulino <lcapitulino@...hat.com>,
        Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Wanpeng Li <kernellwp@...il.com>,
        Rik van Riel <riel@...hat.com>
Subject: Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

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