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: <20180328141645.GF13942@piout.net>
Date:   Wed, 28 Mar 2018 16:16:45 +0200
From:   Alexandre Belloni <alexandre.belloni@...tlin.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>
Cc:     Alexander Dahl <ada@...rsis.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v3 0/6] clocksource: rework Atmel TCB timer driver

On 28/03/2018 at 15:03:11 +0200, Daniel Lezcano wrote:
> On 28/03/2018 12:29, Alexander Dahl wrote:
> > Hello Daniel,
> > 
> > Am Dienstag, 27. März 2018, 13:30:22 CEST schrieb Daniel Lezcano:
> >> Can you can give a rough amount for the irq rate on the timer ?
> > 
> > I used itop [1] now to get a rough estimate. First with kernel v4.14.29-rt25 
> > (fully preempt RT):
> > 
> > INT                NAME          RATE             MAX
> >  19 [ vel     tc_clkevt]   397 Ints/s     (max:   432)
> >  26 [      vel     eth0]     4 Ints/s     (max:    38)
> > 
> > Next test with kernel v4.15.13 gives (slightly slower, but non-RT):
> > 
> > INT                NAME          RATE             MAX
> >  19 [ vel     tc_clkevt]   248 Ints/s     (max:   273)
> >  26 [      vel     eth0]     4 Ints/s     (max:    11)
> > 
> > With kernel v4.16-rc7 plus this patch series and tcb as clocksource:
> > 
> > INT                NAME          RATE             MAX
> >  17 [vel     timer@...a]  2164 Ints/s     (max:  2183)
> >  26 [      vel     eth0]     5 Ints/s     (max:    10)
> > 
> > Is this the information you wanted? If not, could you point me on how to get 
> > the requested irq rate?
> 
> It is perfect. Thanks!
> 
> It confirms what I was worried about: the clocksource wraps up too
> quickly thus raising an interrupt every 400us. That is why I asked
> Alexande about a prescalar register.
> 

The code should behave exactly the same between the previous and the new
driver. The interrupt is not coming from the clocksource but from the
clockevent and it is already on the slowest clock, the 32kHz one.


-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ