linux-kernel - Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest

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: <dda160a8d78b44dbc310759502a49afc@kernel.org>
Date:   Tue, 21 Apr 2020 15:09:35 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     Valentin Schneider <valentin.schneider@....com>,
        Qais Yousef <qais.yousef@....com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Yury Norov <yury.norov@...il.com>,
        Paul Turner <pjt@...gle.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Josh Don <joshdon@...gle.com>,
        Pavan Kondeti <pkondeti@...eaurora.org>,
        linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq()

On 2020-04-21 14:18, Valentin Schneider wrote:
> On 21/04/20 13:13, Qais Yousef wrote:

[...]

>> I CCed Marc who's the maintainer of this file who can clarify better 
>> if this
>> really breaks anything.
>> 
>> If any interrupt expects to be affined to a specific CPU then this 
>> must be
>> described in DT/driver. I think the GIC controller is free to 
>> distribute them
>> to any cpu otherwise if !force. Which is usually done by irq_balancer 
>> anyway
>> in userspace, IIUC.
>> 
>> I don't see how cpumask_any_and() break anything here too. I actually 
>> think it
>> improves on things by better distribute the irqs on the system by 
>> default.

That's a pretty bold statement. Unfortunately, it isn't universally 
true.
Some workload will be very happy with interrupts spread all over the 
map,
and some others will suffer from it because, well, it interrupts 
userspace.

> As you say, if someone wants smarter IRQ affinity they can do 
> irq_balancer
> and whatnot. The default kernel policy for now has been to shove 
> everything
> on the lowest-numbered CPU, and I see no valid reason to change that.

Exactly. I would like to keep the kernel policy as simple as possible 
for
non-managed interrupts (managed interrupts are another kettle of fish 
entirely).
Userpace is in control to place things "intelligently", so let's not try 
and
make the kernel smarter than it strictly needs to be.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...