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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.20.1801171028460.21811@nuc-kabylake>
Date:   Wed, 17 Jan 2018 10:32:29 -0600 (CST)
From:   Christopher Lameter <cl@...ux.com>
To:     Mike Galbraith <efault@....de>
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, 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.

> > 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.

> > 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?

> 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. The directness to control is
lost. Instead there is the fog of complexity created by the cgroups that
have various plugins and whatnot.