From: Michael Schmitz <schmitzmic@gmail.com> To: Russell King - ARM Linux <linux@armlinux.org.uk> Cc: Finn Thain <fthain@telegraphics.com.au>, Christoph Hellwig <hch@infradead.org>, Geert Uytterhoeven <geert@linux-m68k.org>, Arnd Bergmann <arnd@arndb.de>, Stephen N Chivers <schivers@csc.com.au>, Thomas Gleixner <tglx@linutronix.de>, Daniel Lezcano <daniel.lezcano@linaro.org>, John Stultz <john.stultz@linaro.org>, linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset Date: Thu, 15 Nov 2018 14:34:22 +1300 [thread overview] Message-ID: <b70ae231-19f2-ef7c-f7ca-0a6486d2cb6b@gmail.com> (raw) In-Reply-To: <20181114075817.GQ30658@n2100.armlinux.org.uk> On 14/11/18 8:58 PM, Russell King - ARM Linux wrote: > >> Are you saying that's not possible on arm, because the current timer rundown >> counter can't be read while the timer is running? >> >> If I were to run a second timer at higher rate for clocksource, but keeping >> the 10 ms timer as clock event (could easily do that by using timer D on >> Atari Falcon) - how would that improve my timekeeping? Clock events still >> only happen 10 ms apart ... > Ah, I think you're talking about something else. > > You seem to be talking about what happens when time keeping interrupts > happen. That's what I understood your comment was about. > I'm talking about the resolution of gettimeofday() and the other > interfaces that are used (eg) for packet capture timestamping and > the like - the _user_ visible effects of the timekeeping system. > > With the existing implementation, all these have better-than-jiffy > resolution - in the case of RPC, that's 500ns, rather than 10ms > which would be the case without gettimeoffset(). Removing > gettimeoffset() as Finn has proposed without preserving that > resolution is simply completely unacceptable. I agree - but Finn had also offered to supply patches to arm that would have added a clocksource_read() function very much like for those m68k platforms that had used gettimeoffset(). I wondered what reason there was for these not to work on arm I now realize you'd never seen that offer. The proposal to drop architectures still relying on arch_gettimeoffset() had been raising enough of a response on linux-m68k to make me conclude that same proposal had been kicked on to other arch MLs affected as well. I'm a bit naive that way. Now your criticism of arch_gettimeoffset() (missing timer rollover because the timer interrupt has been cleared by the interrupt handler) still stands. I just can't find the offset() functions shown in the 5cfc8ee0bb51 patch. Any hints? Cheers, Michael
WARNING: multiple messages have this Message-ID (diff)
From: schmitzmic@gmail.com (Michael Schmitz) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset Date: Thu, 15 Nov 2018 14:34:22 +1300 [thread overview] Message-ID: <b70ae231-19f2-ef7c-f7ca-0a6486d2cb6b@gmail.com> (raw) In-Reply-To: <20181114075817.GQ30658@n2100.armlinux.org.uk> On 14/11/18 8:58 PM, Russell King - ARM Linux wrote: > >> Are you saying that's not possible on arm, because the current timer rundown >> counter can't be read while the timer is running? >> >> If I were to run a second timer at higher rate for clocksource, but keeping >> the 10 ms timer as clock event (could easily do that by using timer D on >> Atari Falcon) - how would that improve my timekeeping? Clock events still >> only happen 10 ms apart ... > Ah, I think you're talking about something else. > > You seem to be talking about what happens when time keeping interrupts > happen. That's what I understood your comment was about. > I'm talking about the resolution of gettimeofday() and the other > interfaces that are used (eg) for packet capture timestamping and > the like - the _user_ visible effects of the timekeeping system. > > With the existing implementation, all these have better-than-jiffy > resolution - in the case of RPC, that's 500ns, rather than 10ms > which would be the case without gettimeoffset(). Removing > gettimeoffset() as Finn has proposed without preserving that > resolution is simply completely unacceptable. I agree - but Finn had also offered to supply patches to arm that would have added a clocksource_read() function very much like for those m68k platforms that had used gettimeoffset(). I wondered what reason there was for these not to work on arm I now realize you'd never seen that offer. The proposal to drop architectures still relying on arch_gettimeoffset() had been raising enough of a response on linux-m68k to make me conclude that same proposal had been kicked on to other arch MLs affected as well. I'm a bit naive that way. Now your criticism of arch_gettimeoffset() (missing timer rollover because the timer interrupt has been cleared by the interrupt handler) still stands. I just can't find the offset() functions shown in the 5cfc8ee0bb51 patch. Any hints? Cheers, ??? Michael
next prev parent reply other threads:[~2018-11-15 1:34 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-12 4:12 [RFC PATCH 00/13] m68k: Drop arch_gettimeoffset and adopt clocksource API Finn Thain 2018-11-12 4:12 ` [RFC PATCH 08/13] m68k: atari: Convert to " Finn Thain 2018-11-12 4:12 ` [RFC PATCH 04/13] m68k: mac: Clean up unused timer definitions Finn Thain 2018-11-12 4:12 ` [RFC PATCH 10/13] m68k: hp300: Convert to clocksource API Finn Thain 2018-11-12 4:12 ` [RFC PATCH 11/13] m68k: mac: " Finn Thain 2018-11-12 4:12 ` [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset Finn Thain 2018-11-12 4:12 ` Finn Thain 2018-11-12 8:34 ` Christoph Hellwig 2018-11-12 8:34 ` Christoph Hellwig 2018-11-13 3:39 ` Finn Thain 2018-11-13 3:39 ` Finn Thain 2018-11-13 9:20 ` Russell King - ARM Linux 2018-11-13 9:20 ` Russell King - ARM Linux 2018-11-13 21:55 ` Finn Thain 2018-11-13 21:55 ` Finn Thain 2018-11-13 23:43 ` Russell King - ARM Linux 2018-11-13 23:43 ` Russell King - ARM Linux 2018-11-14 1:35 ` Michael Schmitz 2018-11-14 1:35 ` Michael Schmitz 2018-11-14 7:58 ` Russell King - ARM Linux 2018-11-14 7:58 ` Russell King - ARM Linux 2018-11-15 1:34 ` Michael Schmitz [this message] 2018-11-15 1:34 ` Michael Schmitz 2018-11-14 3:17 ` Finn Thain 2018-11-14 3:17 ` Finn Thain 2018-11-14 14:16 ` Russell King - ARM Linux 2018-11-14 14:16 ` Russell King - ARM Linux 2018-11-14 14:58 ` Geert Uytterhoeven 2018-11-14 14:58 ` Geert Uytterhoeven 2018-11-14 18:11 ` Russell King - ARM Linux 2018-11-14 18:11 ` Russell King - ARM Linux 2018-11-15 4:12 ` Finn Thain 2018-11-15 4:12 ` Finn Thain 2018-11-16 17:47 ` Russell King - ARM Linux 2018-11-16 17:47 ` Russell King - ARM Linux 2018-11-16 22:49 ` Finn Thain 2018-11-16 22:49 ` Finn Thain 2018-11-17 3:00 ` Michael Schmitz 2018-11-17 3:00 ` Michael Schmitz 2018-11-14 12:05 ` Russell King - ARM Linux 2018-11-14 12:05 ` Russell King - ARM Linux 2018-11-12 4:12 ` [RFC PATCH 02/13] m68k: " Finn Thain 2018-11-12 4:12 ` [RFC PATCH 07/13] m68k: amiga: Convert to clocksource API Finn Thain 2018-11-12 9:02 ` Geert Uytterhoeven 2018-11-12 9:21 ` Finn Thain 2018-11-12 4:12 ` [RFC PATCH 09/13] m68k: bvme6000: " Finn Thain 2018-11-12 4:12 ` [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET Finn Thain 2018-11-12 9:00 ` Geert Uytterhoeven 2018-11-12 9:06 ` Finn Thain 2018-11-13 2:29 ` Michael Schmitz 2018-11-13 3:14 ` Finn Thain 2018-11-13 4:50 ` Michael Schmitz 2018-11-13 6:15 ` Finn Thain 2018-11-13 8:24 ` Michael Schmitz 2018-11-13 22:11 ` Finn Thain 2018-11-14 1:08 ` Michael Schmitz 2018-11-14 2:58 ` Michael Schmitz 2018-11-14 23:54 ` Michael Schmitz 2018-11-15 4:37 ` Finn Thain 2018-11-15 6:35 ` Michael Schmitz 2018-11-16 0:04 ` Finn Thain 2018-11-12 4:12 ` [RFC PATCH 13/13] m68k: mvme16x: Convert to clocksource API Finn Thain 2018-11-12 18:37 ` Thomas Gleixner 2018-11-13 0:11 ` Finn Thain 2018-11-13 22:04 ` Finn Thain 2018-11-13 22:10 ` [RFC PATCH 13/13] m68k: mvme16x: Convert to clocksource APIy Thomas Gleixner 2018-11-13 22:33 ` Finn Thain 2018-11-18 17:12 ` Thomas Gleixner 2018-11-12 4:12 ` [RFC PATCH 03/13] m68k: mac: Fix VIA timer counter accesses Finn Thain 2018-11-12 4:12 ` [RFC PATCH 12/13] m68k: mvme147: Convert to clocksource API Finn Thain 2018-11-12 4:12 ` [RFC PATCH 05/13] m68k: apollo, q40, sun3, sun3x: Remove arch_gettimeoffset implementations Finn Thain
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=b70ae231-19f2-ef7c-f7ca-0a6486d2cb6b@gmail.com \ --to=schmitzmic@gmail.com \ --cc=arnd@arndb.de \ --cc=daniel.lezcano@linaro.org \ --cc=fthain@telegraphics.com.au \ --cc=geert@linux-m68k.org \ --cc=hch@infradead.org \ --cc=john.stultz@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=linux@armlinux.org.uk \ --cc=schivers@csc.com.au \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.