linux-kernel - Re: [RFC PATCH RT 0/2] Add PINNED

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: <20190221084659.GK21785@localhost.localdomain>
Date:   Thu, 21 Feb 2019 09:46:59 +0100
From:   Juri Lelli <juri.lelli@...hat.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     tglx@...utronix.de, linux-rt-users@...r.kernel.org,
        peterz@...radead.org, linux-kernel@...r.kernel.org,
        bristot@...hat.com, williams@...hat.com
Subject: Re: [RFC PATCH RT 0/2] Add PINNED_HARD mode to hrtimers

On 20/02/19 16:30, Sebastian Andrzej Siewior wrote:
> On 2019-02-20 08:47:51 [+0100], Juri Lelli wrote:
> > > In this case you prepare the wakeup and then wake the CPU anyway. There
> > > should be no downside to this unless the housekeeping CPU is busy and in
> > > irq-off regions which would increase the latency. Also in case of
> > > 	cyclictest -d0
> > > 
> > > the one CPU would have to process all timers. So the latency will be
> > > worse compared to every CPU does its own wakeup. And on RT you probably
> > > do not want to do deep idle anyway.
> > 
> > Mmm, right. But, still very much dependent on the workload, I understand
> > you are saying? So, no one size fits all solution.
> 
> Now that I slept over it, I think it makes sense from RT point of view
> to always pin the timer. I'm not sure if we want to swap the sysctl or
> make the PINNED change like you suggested.

My thinking was that it would be nice to be able to discern between
timers coming from RT and !RT tasks so that the latter can be migrated
to housekeeping CPUs, leaving potentially isolated CPUs to deal with the
former only.

Not sure we can achieve this "best of both worlds" policy any way we set
the sysctl default to be.

Thanks,

- Juri