linux-kernel - Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LNX.2.21.1811131700010.366@nippy.intranet>
Date:   Tue, 13 Nov 2018 17:15:02 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Michael Schmitz <schmitzmic@...il.com>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Stephen N Chivers <schivers@....com.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        John Stultz <john.stultz@...aro.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Philip Blundell <philb@....org>,
        Joshua Thompson <funaho@...ai.org>
Subject: Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

On Tue, 13 Nov 2018, Michael Schmitz wrote:

> 
> > (It appears that a QEMU-emulated Mac does not benefit from having a 
> > clocksource that's more accurate than the 'jiffies' clocksource, in 
> > spite of "clocksource: Switched to clocksource via1".)
> 
> With the current code, kernel log timestamps have 10 ms resolution on 
> Atari. Time resolution of times reported by initcall_debug is roughly 40 
> us. I'd expect that changes with falling back to jiffies only. Might be 
> worth a try on QEMU Mac.

The initcall debug output shows the same precision as my earlier tests 
with userland. The VIA timer only gets updated when QEMU wants to update 
it, which seems to be about every 9765 us. Hence, using the 'jiffies' 
clocksource would be effectively no regression for a virtual Mac.

--