Re: Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi Thomas, On Fri, Jun 28, 2013 at 04:02:23PM +0200, Thomas Gleixner wrote: > On Fri, 28 Jun 2013, 张猛 wrote: > > > The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ > > > does not seem to contain any details about what bad things may happen > > > if we try to read CNT64_LO_REG while latching is still in progress and > > > CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. > > > I can imagine the following possible scenarios: > > > 1. We read either the old stale CNT64_LO_REG value or the new > > > correct value. > > > 2. We read either the old stale CNT64_LO_REG value or the new > > > correct value, or some random garbage. > > > 3. The processor may deadlock, eat your dog, or do some other > > > nasty thing. > > > > > > In the case of 1, we probably can get away without using any spinlocks? > > > > About the 64bits counter, the latch bit is needed because of the > > asynchronous circuit. > > The internal circuit of 64bits counter is working under 24Mhz clock, and > > CNT_LO/HI > > is read with APB clock. So the clock synchronize is needed. The function of > > the latch > > is synchronous the 64bits counter from 24Mhz clock domain to APB clock > > domain. > > So, if the latch is not completely, value of the CNT_LO/HI maybe a random > > value, because > > some bits are latched, but others are not. So, the CNT_LO/HI should be read > > after > > latch is completely. > > The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 > > micro-second. > > > > I really wonder why we're trying to use that timer. AFAICT the A10 has > another six 32bit timers which do not have this restriction and the > clocksoure/sched_clock implementation works nicely with 32 bits. So > what's the point of using that 64 bit counter if it's horrible to > access? Yes, you're right. I actually wanted at first not to use a timer for this since we had a counter to do just that. But that's true that actually using a timer would make the code simpler and presumably faster as well. I'll change this in the v2. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, Jun 28, 2013 at 01:29:12PM +0300, Siarhei Siamashka wrote: > > NOTICE: This e-mail and any included attachments are intended only > > for the sole use of named and intended recipient (s) only. If you > > are the named and intended recipient, please note that the > > information contained in this email and its embedded files are > > confidential and privileged. If you are neither the intended nor > > named recipient, you are hereby notified that any unauthorized > > review, use, disclosure, dissemination, distribution, or copying of > > this communication, or any of its contents, is strictly prohibited. > > Please reply to the sender and destroy the original message and all > > your records of this message (whether electronic or otherwise). > > Furthermore, you should not disclose to any other person, use, copy > > or disseminate the contents of this e-mail and/or the documents > > accompanying it. > > Ugh, just spotted this at the bottom. > > I believe that by sending this information to LKML and the other > public mailing lists, the intended recipient is "the whole world", > hence most of the stated clauses (for example related to "any other > person") can be safely optimized out. Still this does not sound > very nice. I hope that the original intention was to authorize > sharing and using this information. Please correct me if I'm wrong. Come on. This is obviously an automated addition made by the SMTP server. While it definitely is ironic since it is sent to a public mailing list, is your comment here really needed? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, 28 Jun 2013, 张猛 wrote: > > The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ > > does not seem to contain any details about what bad things may happen > > if we try to read CNT64_LO_REG while latching is still in progress and > > CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. > > I can imagine the following possible scenarios: > > 1. We read either the old stale CNT64_LO_REG value or the new > > correct value. > > 2. We read either the old stale CNT64_LO_REG value or the new > > correct value, or some random garbage. > > 3. The processor may deadlock, eat your dog, or do some other > > nasty thing. > > > > In the case of 1, we probably can get away without using any spinlocks? > > About the 64bits counter, the latch bit is needed because of the asynchronous > circuit. > The internal circuit of 64bits counter is working under 24Mhz clock, and > CNT_LO/HI > is read with APB clock. So the clock synchronize is needed. The function of > the latch > is synchronous the 64bits counter from 24Mhz clock domain to APB clock domain. > So, if the latch is not completely, value of the CNT_LO/HI maybe a random > value, because > some bits are latched, but others are not. So, the CNT_LO/HI should be read > after > latch is completely. > The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 > micro-second. > I really wonder why we're trying to use that timer. AFAICT the A10 has another six 32bit timers which do not have this restriction and the clocksoure/sched_clock implementation works nicely with 32 bits. So what's the point of using that 64 bit counter if it's horrible to access? Thanks, tglx
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, 28 Jun 2013 12:26:10 +0200 (CEST) Thomas Gleixner wrote: > On Fri, 28 Jun 2013, Siarhei Siamashka wrote: > > On Fri, 28 Jun 2013 09:43:37 +0800 > > 张猛 wrote: > > > > > > The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ > > > > does not seem to contain any details about what bad things may happen > > > > if we try to read CNT64_LO_REG while latching is still in progress and > > > > CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. > > > > I can imagine the following possible scenarios: > > > > 1. We read either the old stale CNT64_LO_REG value or the new > > > > correct value. > > > > 2. We read either the old stale CNT64_LO_REG value or the new > > > > correct value, or some random garbage. > > > > 3. The processor may deadlock, eat your dog, or do some other > > > > nasty thing. > > > > > > > > In the case of 1, we probably can get away without using any spinlocks? > > > > > > About the 64bits counter, the latch bit is needed because of the > > > asynchronous circuit. The internal circuit of 64bits counter is > > > working under 24Mhz clock, and CNT_LO/HI is read with APB clock. > > > So the clock synchronize is needed. The function of the latch is > > > synchronous the 64bits counter from 24Mhz clock domain to APB clock > > > domain. So, if the latch is not completely, value of the CNT_LO/HI > > > maybe a random value, because some bits are latched, but others are > > > not. So, the CNT_LO/HI should be read after latch is completely. > > > The latch just takes 3 cycles of 24Mhz clock, the time is nearly > > > 0.125 micro-second. > > > > Thanks for the clarification! It is very much appreciated. > > > > So basically we get scenario 2, which still allows some optimizations > > compared to scenario 3. On single-core systems (Allwinner A10), it > > probably makes sense to avoid spinlocks overhead and just place > > Spinlocks are NOPs on UP and just disable preemption, but they > provide you the same ordering guarantees as spinlocks on SMP. So no > special case optimization necessary. Still I would not want some high priority and latency sensitive junk (such as pulseaudio for example) not to get scheduled at the right time because of some low priority gettimeofday spammer application. The time spent latching and reading these counters is non negligible. Though I agree Maxime that first we need an initial implementation, which just works safely. And then we can optimize it by testing real use cases and providing the relevant benchmark numbers. Knowing the precise details about the hardware helps. But enough bikeshedding, it's time for me to shut up :) -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi Hans, On Thu, Jun 27, 2013 at 08:13:56PM +0200, Hans de Goede wrote: > >Siarhei however notes that even higher-end SoCs like the exynos5 have > >similar performances with that regard. So I'm not sure we can do > >something about it, except what is suggested in the above mail, which > >looks rather unsafe. > > > >Anyway, like you said, we have no easy other solution, and we lacked > >such support until now. > > > >So why not merge this code for now, and try to optimise it later if we > >find it's needed. > > That is fine with me, I just wanted to share that this has shown as > a bottleneck in some benchmarks in case anyone has a clever idea to > fix it ... And you were right, since I wasn't aware of such discussion. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, 28 Jun 2013, Siarhei Siamashka wrote: > On Fri, 28 Jun 2013 09:43:37 +0800 > 张猛 wrote: > > > > The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ > > > does not seem to contain any details about what bad things may happen > > > if we try to read CNT64_LO_REG while latching is still in progress and > > > CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. > > > I can imagine the following possible scenarios: > > > 1. We read either the old stale CNT64_LO_REG value or the new > > > correct value. > > > 2. We read either the old stale CNT64_LO_REG value or the new > > > correct value, or some random garbage. > > > 3. The processor may deadlock, eat your dog, or do some other > > > nasty thing. > > > > > > In the case of 1, we probably can get away without using any spinlocks? > > > > About the 64bits counter, the latch bit is needed because of the > > asynchronous circuit. The internal circuit of 64bits counter is > > working under 24Mhz clock, and CNT_LO/HI is read with APB clock. > > So the clock synchronize is needed. The function of the latch is > > synchronous the 64bits counter from 24Mhz clock domain to APB clock > > domain. So, if the latch is not completely, value of the CNT_LO/HI > > maybe a random value, because some bits are latched, but others are > > not. So, the CNT_LO/HI should be read after latch is completely. > > The latch just takes 3 cycles of 24Mhz clock, the time is nearly > > 0.125 micro-second. > > Thanks for the clarification! It is very much appreciated. > > So basically we get scenario 2, which still allows some optimizations > compared to scenario 3. On single-core systems (Allwinner A10), it > probably makes sense to avoid spinlocks overhead and just place Spinlocks are NOPs on UP and just disable preemption, but they provide you the same ordering guarantees as spinlocks on SMP. So no special case optimization necessary. Thanks, tglx
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/27/2013 10:26 PM, Siarhei Siamashka wrote: On Thu, 27 Jun 2013 18:54:36 +0200 Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: I notice that unlike the sunxi-3.4 code you don't do any locking, so how do you stop 2 clocksource calls from racing (and thus getting a possible wrong value because of things not being properly latched) ? Hmm, right. I'll add a spinlock. I think the best would be to ask the Allwinner people (it's good to have them in CC, right?) whether anything wrong can happen because of "things not being properly latched". The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? No, because if ie CNT64_LO_REG old is 0x and CNT64_LO_REG new is say 0x0001, and we do get the new CNT64_HI_REG things will break. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/27/2013 10:26 PM, Siarhei Siamashka wrote: On Thu, 27 Jun 2013 18:54:36 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: I notice that unlike the sunxi-3.4 code you don't do any locking, so how do you stop 2 clocksource calls from racing (and thus getting a possible wrong value because of things not being properly latched) ? Hmm, right. I'll add a spinlock. I think the best would be to ask the Allwinner people (it's good to have them in CC, right?) whether anything wrong can happen because of things not being properly latched. The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? No, because if ie CNT64_LO_REG old is 0x and CNT64_LO_REG new is say 0x0001, and we do get the new CNT64_HI_REG things will break. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, 28 Jun 2013, Siarhei Siamashka wrote: On Fri, 28 Jun 2013 09:43:37 +0800 张猛 ke...@allwinnertech.com wrote: The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? About the 64bits counter, the latch bit is needed because of the asynchronous circuit. The internal circuit of 64bits counter is working under 24Mhz clock, and CNT_LO/HI is read with APB clock. So the clock synchronize is needed. The function of the latch is synchronous the 64bits counter from 24Mhz clock domain to APB clock domain. So, if the latch is not completely, value of the CNT_LO/HI maybe a random value, because some bits are latched, but others are not. So, the CNT_LO/HI should be read after latch is completely. The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 micro-second. Thanks for the clarification! It is very much appreciated. So basically we get scenario 2, which still allows some optimizations compared to scenario 3. On single-core systems (Allwinner A10), it probably makes sense to avoid spinlocks overhead and just place Spinlocks are NOPs on UP and just disable preemption, but they provide you the same ordering guarantees as spinlocks on SMP. So no special case optimization necessary. Thanks, tglx
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi Hans, On Thu, Jun 27, 2013 at 08:13:56PM +0200, Hans de Goede wrote: Siarhei however notes that even higher-end SoCs like the exynos5 have similar performances with that regard. So I'm not sure we can do something about it, except what is suggested in the above mail, which looks rather unsafe. Anyway, like you said, we have no easy other solution, and we lacked such support until now. So why not merge this code for now, and try to optimise it later if we find it's needed. That is fine with me, I just wanted to share that this has shown as a bottleneck in some benchmarks in case anyone has a clever idea to fix it ... And you were right, since I wasn't aware of such discussion. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, 28 Jun 2013 12:26:10 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Fri, 28 Jun 2013, Siarhei Siamashka wrote: On Fri, 28 Jun 2013 09:43:37 +0800 张猛 ke...@allwinnertech.com wrote: The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? About the 64bits counter, the latch bit is needed because of the asynchronous circuit. The internal circuit of 64bits counter is working under 24Mhz clock, and CNT_LO/HI is read with APB clock. So the clock synchronize is needed. The function of the latch is synchronous the 64bits counter from 24Mhz clock domain to APB clock domain. So, if the latch is not completely, value of the CNT_LO/HI maybe a random value, because some bits are latched, but others are not. So, the CNT_LO/HI should be read after latch is completely. The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 micro-second. Thanks for the clarification! It is very much appreciated. So basically we get scenario 2, which still allows some optimizations compared to scenario 3. On single-core systems (Allwinner A10), it probably makes sense to avoid spinlocks overhead and just place Spinlocks are NOPs on UP and just disable preemption, but they provide you the same ordering guarantees as spinlocks on SMP. So no special case optimization necessary. Still I would not want some high priority and latency sensitive junk (such as pulseaudio for example) not to get scheduled at the right time because of some low priority gettimeofday spammer application. The time spent latching and reading these counters is non negligible. Though I agree Maxime that first we need an initial implementation, which just works safely. And then we can optimize it by testing real use cases and providing the relevant benchmark numbers. Knowing the precise details about the hardware helps. But enough bikeshedding, it's time for me to shut up :) -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, 28 Jun 2013, 张猛 wrote: The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? About the 64bits counter, the latch bit is needed because of the asynchronous circuit. The internal circuit of 64bits counter is working under 24Mhz clock, and CNT_LO/HI is read with APB clock. So the clock synchronize is needed. The function of the latch is synchronous the 64bits counter from 24Mhz clock domain to APB clock domain. So, if the latch is not completely, value of the CNT_LO/HI maybe a random value, because some bits are latched, but others are not. So, the CNT_LO/HI should be read after latch is completely. The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 micro-second. I really wonder why we're trying to use that timer. AFAICT the A10 has another six 32bit timers which do not have this restriction and the clocksoure/sched_clock implementation works nicely with 32 bits. So what's the point of using that 64 bit counter if it's horrible to access? Thanks, tglx
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Fri, Jun 28, 2013 at 01:29:12PM +0300, Siarhei Siamashka wrote: NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. Ugh, just spotted this at the bottom. I believe that by sending this information to LKML and the other public mailing lists, the intended recipient is the whole world, hence most of the stated clauses (for example related to any other person) can be safely optimized out. Still this does not sound very nice. I hope that the original intention was to authorize sharing and using this information. Please correct me if I'm wrong. Come on. This is obviously an automated addition made by the SMTP server. While it definitely is ironic since it is sent to a public mailing list, is your comment here really needed? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi Thomas, On Fri, Jun 28, 2013 at 04:02:23PM +0200, Thomas Gleixner wrote: On Fri, 28 Jun 2013, 张猛 wrote: The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? About the 64bits counter, the latch bit is needed because of the asynchronous circuit. The internal circuit of 64bits counter is working under 24Mhz clock, and CNT_LO/HI is read with APB clock. So the clock synchronize is needed. The function of the latch is synchronous the 64bits counter from 24Mhz clock domain to APB clock domain. So, if the latch is not completely, value of the CNT_LO/HI maybe a random value, because some bits are latched, but others are not. So, the CNT_LO/HI should be read after latch is completely. The latch just takes 3 cycles of 24Mhz clock, the time is nearly 0.125 micro-second. I really wonder why we're trying to use that timer. AFAICT the A10 has another six 32bit timers which do not have this restriction and the clocksoure/sched_clock implementation works nicely with 32 bits. So what's the point of using that 64 bit counter if it's horrible to access? Yes, you're right. I actually wanted at first not to use a timer for this since we had a counter to do just that. But that's true that actually using a timer would make the code simpler and presumably faster as well. I'll change this in the v2. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Thu, 27 Jun 2013 18:54:36 +0200 Maxime Ripard wrote: > On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: > > I notice that unlike the sunxi-3.4 code you don't do any locking, > > so how do you stop 2 clocksource calls from racing (and thus > > getting a possible wrong value because of things not > > being properly latched) ? > > Hmm, right. I'll add a spinlock. I think the best would be to ask the Allwinner people (it's good to have them in CC, right?) whether anything wrong can happen because of "things not being properly latched". The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/27/2013 06:54 PM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: Hi, On 06/27/2013 11:43 AM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? The original discussion should be somewhere here: https://groups.google.com/forum/#!forum/linux-sunxi But I could not find it (it is probably hidden under an unlogical subject). I searched a bit and it seems to be that discussion: https://groups.google.com/d/msg/linux-sunxi/gaTDngPT7Is/oeLtWb1N1wIJ Looking at my own notes (a small TODO file), I've written down that the reporter reports: -current clocksource can cause us to run with interrupts disabled for 17% of the time, see "perf top" output This is with a workload which does a lot of gettimeofday calls. Siarhei however notes that even higher-end SoCs like the exynos5 have similar performances with that regard. So I'm not sure we can do something about it, except what is suggested in the above mail, which looks rather unsafe. Anyway, like you said, we have no easy other solution, and we lacked such support until now. So why not merge this code for now, and try to optimise it later if we find it's needed. That is fine with me, I just wanted to share that this has shown as a bottleneck in some benchmarks in case anyone has a clever idea to fix it ... Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: > Hi, > > On 06/27/2013 11:43 AM, Maxime Ripard wrote: > >On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: > >>Hi, > >> > >>On 06/26/2013 11:16 PM, Maxime Ripard wrote: > >>>Hi everyone, > >>> > >> > >> > >> > >>>It also finally adds a clocksource from the free running counter found in > >>>the > >>>A10/A13 SoCs. > >> > >>Hmm, have you benchmarked this? There have been reports from linux-sunxi > >>kernel > >>users (xbmc project) that the waiting for the latch is quite slow. Note we > >>don't have anything better yet in the linux-sunxi kernel. > > > >No. I didn't. > > > >Do you have any pointers to these discussions? > > > > The original discussion should be somewhere here: > https://groups.google.com/forum/#!forum/linux-sunxi > > But I could not find it (it is probably hidden under > an unlogical subject). I searched a bit and it seems to be that discussion: https://groups.google.com/d/msg/linux-sunxi/gaTDngPT7Is/oeLtWb1N1wIJ > Looking at my own notes (a small TODO file), I've > written down that the reporter reports: > > -current clocksource can cause us to run with interrupts disabled for 17% > of the time, see "perf top" output > > This is with a workload which does a lot of gettimeofday > calls. Siarhei however notes that even higher-end SoCs like the exynos5 have similar performances with that regard. So I'm not sure we can do something about it, except what is suggested in the above mail, which looks rather unsafe. Anyway, like you said, we have no easy other solution, and we lacked such support until now. So why not merge this code for now, and try to optimise it later if we find it's needed. > I notice that unlike the sunxi-3.4 code you don't do any locking, > so how do you stop 2 clocksource calls from racing (and thus > getting a possible wrong value because of things not > being properly latched) ? Hmm, right. I'll add a spinlock. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/27/2013 11:43 AM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? The original discussion should be somewhere here: https://groups.google.com/forum/#!forum/linux-sunxi But I could not find it (it is probably hidden under an unlogical subject). Looking at my own notes (a small TODO file), I've written down that the reporter reports: -current clocksource can cause us to run with interrupts disabled for 17% of the time, see "perf top" output This is with a workload which does a lot of gettimeofday calls. I notice that unlike the sunxi-3.4 code you don't do any locking, so how do you stop 2 clocksource calls from racing (and thus getting a possible wrong value because of things not being properly latched) ? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: > Hi, > > On 06/26/2013 11:16 PM, Maxime Ripard wrote: > >Hi everyone, > > > > > > >It also finally adds a clocksource from the free running counter found in the > >A10/A13 SoCs. > > Hmm, have you benchmarked this? There have been reports from linux-sunxi > kernel > users (xbmc project) that the waiting for the latch is quite slow. Note we > don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, snip It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, snip It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/27/2013 11:43 AM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, snip It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? The original discussion should be somewhere here: https://groups.google.com/forum/#!forum/linux-sunxi But I could not find it (it is probably hidden under an unlogical subject). Looking at my own notes (a small TODO file), I've written down that the reporter reports: -current clocksource can cause us to run with interrupts disabled for 17% of the time, see perf top output This is with a workload which does a lot of gettimeofday calls. I notice that unlike the sunxi-3.4 code you don't do any locking, so how do you stop 2 clocksource calls from racing (and thus getting a possible wrong value because of things not being properly latched) ? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: Hi, On 06/27/2013 11:43 AM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, snip It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? The original discussion should be somewhere here: https://groups.google.com/forum/#!forum/linux-sunxi But I could not find it (it is probably hidden under an unlogical subject). I searched a bit and it seems to be that discussion: https://groups.google.com/d/msg/linux-sunxi/gaTDngPT7Is/oeLtWb1N1wIJ Looking at my own notes (a small TODO file), I've written down that the reporter reports: -current clocksource can cause us to run with interrupts disabled for 17% of the time, see perf top output This is with a workload which does a lot of gettimeofday calls. Siarhei however notes that even higher-end SoCs like the exynos5 have similar performances with that regard. So I'm not sure we can do something about it, except what is suggested in the above mail, which looks rather unsafe. Anyway, like you said, we have no easy other solution, and we lacked such support until now. So why not merge this code for now, and try to optimise it later if we find it's needed. I notice that unlike the sunxi-3.4 code you don't do any locking, so how do you stop 2 clocksource calls from racing (and thus getting a possible wrong value because of things not being properly latched) ? Hmm, right. I'll add a spinlock. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
Hi, On 06/27/2013 06:54 PM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: Hi, On 06/27/2013 11:43 AM, Maxime Ripard wrote: On Thu, Jun 27, 2013 at 11:27:02AM +0200, Hans de Goede wrote: Hi, On 06/26/2013 11:16 PM, Maxime Ripard wrote: Hi everyone, snip It also finally adds a clocksource from the free running counter found in the A10/A13 SoCs. Hmm, have you benchmarked this? There have been reports from linux-sunxi kernel users (xbmc project) that the waiting for the latch is quite slow. Note we don't have anything better yet in the linux-sunxi kernel. No. I didn't. Do you have any pointers to these discussions? The original discussion should be somewhere here: https://groups.google.com/forum/#!forum/linux-sunxi But I could not find it (it is probably hidden under an unlogical subject). I searched a bit and it seems to be that discussion: https://groups.google.com/d/msg/linux-sunxi/gaTDngPT7Is/oeLtWb1N1wIJ Looking at my own notes (a small TODO file), I've written down that the reporter reports: -current clocksource can cause us to run with interrupts disabled for 17% of the time, see perf top output This is with a workload which does a lot of gettimeofday calls. Siarhei however notes that even higher-end SoCs like the exynos5 have similar performances with that regard. So I'm not sure we can do something about it, except what is suggested in the above mail, which looks rather unsafe. Anyway, like you said, we have no easy other solution, and we lacked such support until now. So why not merge this code for now, and try to optimise it later if we find it's needed. That is fine with me, I just wanted to share that this has shown as a bottleneck in some benchmarks in case anyone has a clever idea to fix it ... Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup
On Thu, 27 Jun 2013 18:54:36 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Jun 27, 2013 at 11:54:11AM +0200, Hans de Goede wrote: I notice that unlike the sunxi-3.4 code you don't do any locking, so how do you stop 2 clocksource calls from racing (and thus getting a possible wrong value because of things not being properly latched) ? Hmm, right. I'll add a spinlock. I think the best would be to ask the Allwinner people (it's good to have them in CC, right?) whether anything wrong can happen because of things not being properly latched. The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem to contain any details about what bad things may happen if we try to read CNT64_LO_REG while latching is still in progress and CNT64_RL_EN bit in CNT64_CTRL_REG has not changed to zero yet. I can imagine the following possible scenarios: 1. We read either the old stale CNT64_LO_REG value or the new correct value. 2. We read either the old stale CNT64_LO_REG value or the new correct value, or some random garbage. 3. The processor may deadlock, eat your dog, or do some other nasty thing. In the case of 1, we probably can get away without using any spinlocks? -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
