linux-kernel - Re: [RFC PATCH 0/2] Adjust CFS loadbalance to adapt QEMU CPU topology.

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] [day] [month] [year] [list]

Message-ID: <20230724140746.GB3735636@hirez.programming.kicks-ass.net>
Date:   Mon, 24 Jul 2023 16:07:46 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     luoben@...ux.alibaba.com
Cc:     Vincent Guittot <vincent.guittot@...aro.org>, pbonzini@...hat.com,
        mikelley@...rosoft.com, yu.c.chen@...el.com,
        "Kenan.Liu" <Kenan.Liu@...ux.alibaba.com>, mingo@...hat.com,
        juri.lelli@...hat.com, dietmar.eggemann@....com,
        rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, vschneid@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] Adjust CFS loadbalance to adapt QEMU CPU
 topology.

On Mon, Jul 24, 2023 at 02:57:57PM +0800, luoben@...ux.alibaba.com wrote:

> > Right, why is this a problem? Hyperthreads are supposed to be symmetric,
> > it doesn't matter which of the two are active, the important thing is to
> > only have one active if we can.
> > 
> > (Unlike Power7, they have asymmetric SMT)
> > 
> 
> hi Peter and Vincent,
> 
> Some upper-level monitoring logic may take the CPU usage as a metric for
> computing resource scaling. Imbalanced scheduling can create the illusion
> of CPU resource scarcity, leading to more frequent triggering of resource
> expansion by the upper-level scheduling system. However, this is actually
> a waste of resources. So, we think this may be a problem.

This is a problem of your monitoring logic -- there is absolutely no
functional problem with the kernel AFAICT.

Teach the thing about SMT instead.

> Could you please take a further look at PATCH#2? We found that the default
> 'nr' value did not perform well under our scenario, and we believe that
> adjustable variables would be more appropriate.

That patch is tweaking default disabled code -- which we should be
removing sometime soon I suppose. So no.