linux-kernel - Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300

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: <alpine.LNX.2.21.1811251350500.10@nippy.intranet>
Date:   Sun, 25 Nov 2018 14:25:25 +1100 (AEDT)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Michael Schmitz <schmitzmic@...il.com>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Kars de Jong <jongk@...ux-m68k.org>,
        Philip Blundell <philb@....org>,
        Andreas Schwab <schwab@...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>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

On Sun, 25 Nov 2018, Michael Schmitz wrote:

> > We can benchmark gettimeofday syscalls on elgar but is that hardware 
> > representative of other relevant models?
> 
> I suppose the CIA is on the main board, so running with the slower clock 
> speed that you'd see with a vanilla Amiga without 060 accelerator board. 
> Ought to be representative enough?
> 

Not really. An accelerated CPU clock exaggerates the slowdown factor, 
given the fixed 0.7 MHz CIA clock.

The "(ticks > jiffy_ticks / 2)" conditional won't make anything worse even 
if interrupt latency is already too high, so I'm inclined towards the more 
prudent option. This patch series is already complicated enough.

In anycase, I'd prefer not to speculate about interrupt priorities or 
latencies when the list probably has people who know the answers.

--