linux-kernel - Re: [PATCH] timers: Make the lower-level timer function first call than higher-level

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]

Date:   Wed, 28 Nov 2018 16:15:50 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Muchun Song <smuchun@...il.com>
cc:     John Stultz <john.stultz@...aro.org>, sboyd@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] timers: Make the lower-level timer function first call
 than higher-level

Song,

On Wed, 21 Nov 2018, Thomas Gleixner wrote:
> On Tue, 20 Nov 2018, Muchun Song wrote:
> > Follow the current code logic, the timer0 function is called until the
> > function call of timer1-5 is completed. So the delay of timer0 is the time
> > spent by other timer function calls. If we can call the timer function in
> > the following order, this should be more friendly to lower-level timers.
> > 
> >         timer0->timer1->->timer2->->timer3->->timer4->->timer5
> > 
> > Although not friendly to higher-level timers, higher-level has larger
> > granularity. Therefore the delay has less impact on higher-level.
> 
> Well yes, that's clear. But is it a problem in practice and if so, what is
> the measurable benefit.

Polite reminder. Can you please describe what the practical relevance is of
that and what real world problem you are solving? Ideally with numbers
backing it up.

Thanks,

	tglx