Prev: execve() returns ENOENT when ld-linux.so isn't found
Next: [V2 PATCH 07/10] of: eliminate calls to dev_archdata_set_node()
From: Richard Henderson on 18 Mar 2010 10:50 On 03/17/2010 07:01 PM, John Stultz wrote: > Alpha has a tsc like rpcc counter that it uses to manage time. > This can be converted to an actual clocksource instead of utilizing > the arch_gettimeoffset method that is really only there for legacy > systems with no continuous counter. With 8 seconds or less between roll-overs, do you actually consider this a continuous counter? I don't. I suggest this be left alone. r~ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: john stultz on 18 Mar 2010 14:00 On Thu, 2010-03-18 at 07:32 -0700, Richard Henderson wrote: > On 03/17/2010 07:01 PM, John Stultz wrote: > > Alpha has a tsc like rpcc counter that it uses to manage time. > > This can be converted to an actual clocksource instead of utilizing > > the arch_gettimeoffset method that is really only there for legacy > > systems with no continuous counter. > > With 8 seconds or less between roll-overs, do you actually consider > this a continuous counter? I don't. I suggest this be left alone. The timekeeping code handles this (although the shift value I picked may need some adjustment - what is the expected counter freq range on alpha?). The ACPI PM counter which is very common on x86 is only 24 bits and rolls over in ~5 seconds. It works fine. However, I'm not maintaining the arch, and this patch isn't limiting the timekeeping core, so the call is really yours. I sent this out on a whim since it looked easy to do. However, while this change is totally optional, I suspect my suggestion about moving to the clockevents code is going to rise in importance. The triplicate timer code paths of non-converted, converted periodic and converted one-shot is difficult to follow. I'll try to find a good example of an easy conversion case (PIT on x86 is not it) and send it your way. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ivan Kokshaysky on 18 Mar 2010 18:10 On Thu, Mar 18, 2010 at 10:55:23AM -0700, john stultz wrote: > On Thu, 2010-03-18 at 07:32 -0700, Richard Henderson wrote: > > On 03/17/2010 07:01 PM, John Stultz wrote: > > > Alpha has a tsc like rpcc counter that it uses to manage time. > > > This can be converted to an actual clocksource instead of utilizing > > > the arch_gettimeoffset method that is really only there for legacy > > > systems with no continuous counter. > > > > With 8 seconds or less between roll-overs, do you actually consider > > this a continuous counter? I don't. I suggest this be left alone. > > The timekeeping code handles this (although the shift value I picked may > need some adjustment - what is the expected counter freq range on > alpha?). The ACPI PM counter which is very common on x86 is only 24 bits > and rolls over in ~5 seconds. It works fine. Yeah, that looks cool. I'm typing this on the 800MHz UP1500 running 2.6.34-rc1 plus your patch, and the timekeeping works fine so far. Though, even after a glance over the clocksource code, I've not gotten yet to how one could estimate the "shift" value... Any hints? And if I recall correctly, production alphas have been clocked in the range of 60-1250 MHz. Ivan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Richard Henderson on 19 Mar 2010 13:20 On 03/19/2010 09:47 AM, Matt Turner wrote: > Richard, if your concerns are met, I'll get this into my tree. Sure. r~ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Weiner on 22 Mar 2010 07:20
Hi, On Fri, Mar 19, 2010 at 12:40:30AM +0300, Ivan Kokshaysky wrote: > On Thu, Mar 18, 2010 at 10:55:23AM -0700, john stultz wrote: > > On Thu, 2010-03-18 at 07:32 -0700, Richard Henderson wrote: > > > On 03/17/2010 07:01 PM, John Stultz wrote: > > > > Alpha has a tsc like rpcc counter that it uses to manage time. > > > > This can be converted to an actual clocksource instead of utilizing > > > > the arch_gettimeoffset method that is really only there for legacy > > > > systems with no continuous counter. > > > > > > With 8 seconds or less between roll-overs, do you actually consider > > > this a continuous counter? I don't. I suggest this be left alone. > > > > The timekeeping code handles this (although the shift value I picked may > > need some adjustment - what is the expected counter freq range on > > alpha?). The ACPI PM counter which is very common on x86 is only 24 bits > > and rolls over in ~5 seconds. It works fine. > > Yeah, that looks cool. I'm typing this on the 800MHz UP1500 running > 2.6.34-rc1 plus your patch, and the timekeeping works fine so far. > > Though, even after a glance over the clocksource code, I've not > gotten yet to how one could estimate the "shift" value... > Any hints? I had the same problem with xtensa and added a comment about what I did in there, maybe it helps: arch/xtensa/kernel/time.c I took the upper bound of the multiplicator (nsecs per counter unit) and subtracted its logarithm from my available 32 bits. The result is the highest possible shift value that works for the clocksource. HTH, Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |