Re: Getting Time Difference

Re: Getting Time Difference

[Jun Sun]

On Tue, Jan 21, 2003 at 07:48:57AM +0200, Gilad Benjamini wrote:
> > In mvsita kernel we introduced an abstraction layer which consists
> > of the following:
> > 
> > readclock_init()
> > readclock()
> > clock_to_usecs()
> > 
> > For MIPS in general, we use the following implementation:
> > 
> > #define readclock_init()
> > #define readclock(low)   do {                           \
> >         db_assert(mips_cpu.options & MIPS_CPU_COUNTER); \
> >         low = read_32bit_cp0_register(CP0_COUNT);       \
> >         } while (0)     
> > #define clock_to_usecs(clocks) ((clocks) / 
> > ((mips_counter_frequency / 1000000)))
> > 
> 
> Thx.
> How would I go about doing readclock to a 64 bit variable ?
> The 32 bit can wrap around pretty fast in today's processors.
>

This interface is meant for short and precise kernel timing
measurement.  Wraping around once does not cause problem as
long as the elapsed clock cycles is less than 2^32.  That gives 
you about 40 secs max interval on a CPU with 100MHz counter
frequency.

Jun

Getting Time Difference

[Gilad Benjamini]

Hi,
I am porting code from a x86 platform.
That code uses rdtsc and cpu_khz to compute
the time difference between two events. Jiffies aren't good enough in this 
case.

Looking through header files I can find a few MIPS replacements.
What is the "right" one to use ?

What is the best way to change the code so it can compile
and run on both platforms ?

Getting Time Difference

[Gilad Benjamini]

Hi,
I am porting code from a x86 platform.
That code uses rdtsc and cpu_khz to compute
the time difference between two events. Jiffies aren't good enough in this 
case.

Looking through header files I can find a few MIPS replacements.
What is the "right" one to use ?

What is the best way to change the code so it can compile
and run on both platforms ?

Re: Getting Time Difference

[Ralf Baechle]

On Thu, Jan 16, 2003 at 06:48:09PM +0200, Gilad Benjamini wrote:

> I am porting code from a x86 platform.
> That code uses rdtsc and cpu_khz to compute
> the time difference between two events. Jiffies aren't good enough in this 
> case.
> 
> Looking through header files I can find a few MIPS replacements.
> What is the "right" one to use ?
> 
> What is the best way to change the code so it can compile
> and run on both platforms ?

Try do_gettimeofday().

  Ralf

Re: Getting Time Difference

[Jun Sun]

On Thu, Jan 16, 2003 at 06:48:09PM +0200, Gilad Benjamini wrote:
> Hi,
> I am porting code from a x86 platform.
> That code uses rdtsc and cpu_khz to compute
> the time difference between two events. Jiffies aren't good enough in this 
> case.
> 
> Looking through header files I can find a few MIPS replacements.
> What is the "right" one to use ?
> 
> What is the best way to change the code so it can compile
> and run on both platforms ?
>

I assume you are doing this inside kernel for some performance
measurement.

In mvsita kernel we introduced an abstraction layer which consists
of the following:

readclock_init()
readclock()
clock_to_usecs()

For MIPS in general, we use the following implementation:

#define readclock_init()
#define readclock(low)   do {                           \
        db_assert(mips_cpu.options & MIPS_CPU_COUNTER); \
        low = read_32bit_cp0_register(CP0_COUNT);       \
        } while (0)     
#define clock_to_usecs(clocks) ((clocks) / ((mips_counter_frequency / 1000000)))

In mvl kernel we always calibrate mips_counter_frequency even if it
is not specified by board code.  This is different from the current
linux-mips.org tree.

Jun 

Re: Getting Time Difference

[Christoph Hellwig]

On Mon, Jan 20, 2003 at 11:50:59AM -0800, Jun Sun wrote:
> I assume you are doing this inside kernel for some performance
> measurement.
> 
> In mvsita kernel we introduced an abstraction layer which consists
> of the following:

Do you have a pointer to the mvista tree (cvs/tarball/rpm/patch)?

Re: Getting Time Difference

[Jun Sun]

On Mon, Jan 20, 2003 at 08:15:31PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 11:50:59AM -0800, Jun Sun wrote:
> > I assume you are doing this inside kernel for some performance
> > measurement.
> > 
> > In mvsita kernel we introduced an abstraction layer which consists
> > of the following:
> 
> Do you have a pointer to the mvista tree (cvs/tarball/rpm/patch)?
>

I don't think you can freely access it.  Check with our marketing people.
Most of the work though is submitted back to the community, which of course
could take quite a while to show up, or sometimes get rejected and never
show up.

Jun

Re: Getting Time Difference

[Christoph Hellwig]

On Mon, Jan 20, 2003 at 12:19:51PM -0800, Jun Sun wrote:
> I don't think you can freely access it.  Check with our marketing people.
> Most of the work though is submitted back to the community, which of course
> could take quite a while to show up, or sometimes get rejected and never
> show up.

That's not exactly a nice attitude :P

Maybe there's some mvista customer here who wants to use his/her right to
freely distribute it so I can add it to the other vendor trees at
kernelnewbies.org?

Re: Getting Time Difference

[Pete Popov]

On Mon, 2003-01-20 at 12:29, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 12:19:51PM -0800, Jun Sun wrote:
> > I don't think you can freely access it.  Check with our marketing people.
> > Most of the work though is submitted back to the community, which of course
> > could take quite a while to show up, or sometimes get rejected and never
> > show up.
> 
> That's not exactly a nice attitude :P

All of that work is submitted to the community. Jun was talking about
the internal source tree not being freely accessible.

> Maybe there's some mvista customer here who wants to use his/her right to
> freely distribute it so I can add it to the other vendor trees at
> kernelnewbies.org?

I think the fact that it's not in the community tree means that it was
submitted but not accepted. Not everything we do for customers is of
interest to the community at large, which is to be expected, but that's
the main reason why sometimes bits get lost and never make it there.

Pete