On Mon, 12 Nov 2018, Michael Schmitz wrote: > I'm wondering if disabling interrupts really is required when updating > the ticks counter in mfp_timer_handler, or whether READ_ONCE() and > WRITE_ONCE() would work as well. >
I get the impression from Documentation/core-api/atomic_ops.rst that the author is opposed to that kind of usage of READ_ONCE() and WRITE_ONCE(). Apparently these operations are to be used solely for avoiding certain compiler optimizations. In this patch series I've used the same synchronization pattern for each platform for expediency. It is probably overkill in some places. But looking at the atari patch agin, I think there is a bug. In atari_read_clk(), clk_total is accessed outside the irq lock. But it is supposed to be synchronized with the timer interrupt handler and timer interrupt flag. I'll have to change this. > Note that there's a mfptimer_handler() in arch/m68k/atari/ataints.c > already (timer D, for polling interrupt-less hardware - I used to have > patches to adjust the rate of that timer at runtime...). Might be best > to rename the two (mfp_timerc_handler(), mfp_timerd_handler()) for > clarity. Or hook that timer function into the generic clocksource timer. > OK, I'll rename them. > > If I understand correctly, removing arch_gettimeoffset without adding > > a clocksource would reduce timer accuracy to 10 ms regardless of > > platform (because that's what the default jiffies clocksource offers). > That's my understanding. I now see that we could quite easily change the > timer C divisor to 10 while retaining the timer C data (246) and obtain > a clocksource rate of 2500. Setting that in the clocksource 'rating' > field will keep the scheduling timer at 100 Hz, is that correct? > The rating is arbitrary AFAICT. I gather that it just allows the clocksource core to select the best clocksource. The more accurate the clocksource, the higher its rating. You can see the available clocksources in dmesg. > With only the timer C interrupt running at increased rate, I don't think > the impact on the system would be all that severe. > If you need more timer accuracy, you'll need a faster oscillator driving the counter. But then you get counter overflow sooner, which may or may not be a problem. This patch series avoids changing any device configuration (clock rates, dividers, interrupt rates etc.) The exception is a VIA driver bug fix patch that is part of this series even though it is not related to the clocksource conversion. That patch got included just because of the mechanics of testing and merging patches. If you were to write a timer patch relevant to -stable, it could go before my series, and I could rebase. Otherwise I suggest that it go afterwards, either at the end of this series or submitted separately with a note about the dependency. -- > Cheers, > > ??? Michael > >