All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Philip Mucci <mucci@cs.utk.edu>
Cc: Linux MIPS <linux-mips@linux-mips.org>
Subject: Re: /dev/cpuid or /proc/cpuinfo
Date: Wed, 1 Feb 2006 11:30:07 +0000	[thread overview]
Message-ID: <20060201113006.GA3562@linux-mips.org> (raw)
In-Reply-To: <1138647269.4077.11.camel@localhost.localdomain>

On Mon, Jan 30, 2006 at 06:54:29PM +0000, Philip Mucci wrote:

> In reference to the performance counting thread we had going earlier,
> I've noticed a 'feature' I need out of MIPS/Linux that isn't currently
> available. This has also recently come up on the oprofile list with one
> of the oprofile/mips tools not being able to grab cpu Mhz
> from /proc/cpuinfo because it's not there.

Surprise - the kernel doesn't actually have that information.  The closest
available would be the counting speed of the c0 count register which - if
something like that is available at all - could be calibrated against an
external counter to figure out the clock speed.  To complicate matters
not all processors have have a c0 counter, it's sometimes incrementing
every cycle but it might just as well counting at half the clock rate and
oh yes, more recently there is clock scaling.

> I have need to execute the mfc0 instruction on the config register and
> grok the results to find out things like cache size etc. In addition, it
> might be nice to also actually be able to find out the clock rate.
> (Currently I grab BogoMIPS and punt.)

Considering above complexities a BogoMIPS-based approach doesn't sound too
bad - but it has other problem to implement since it requires knowing the
exact execution timing.  A think that could be done is meassuring two
loops containing a different number of nops and use that to compute the
execution time for the loop closing branch.  Now knowing that based on
knowing the # of cycles per loop we can compute the clock speed - all it
takes is a timer running at a known speed.

A funny complexity is that some multiprocessor MIPS systems have processors
running at different speeds.  So knowing the clock rate doesn't make life
too much easier ;-)

> On the intel and PPC systems, I believe you can execute similar
> instructions from user mode which makes things easy. However, of course
> an MFC0 is a privileged instruction...meaning that if the value or
> values aren't found in /proc/cpuinfo, I'm s.o.l.

We have a long tradition of emulating instructions, could use that to
permit access to a bunch of cp0 registers from userland ;)

> What does the list think about this? Making a mips /dev/cpuid is a bit
> gross but extending and grokking /proc/cpuinfo is perhaps grosser...and
> many tools do just this (like PAPI and oprofile's opreport...)
> 
> Comments? I'm certainly willing to implement this, but I'd rather 'do it
> right the first time' rather than get rotten vegetables thrown my way.

/proc/cpuinfo is meant to have per processor information so I don't have
a problem with adding cache configuration information.  I was considering
to do so to make such information available for bug reports.

  Ralf

      reply	other threads:[~2006-02-02 11:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-16 15:36 Timer Interrupt Bharathi Subramanian
2006-01-17  7:30 ` Bharathi Subramanian
2006-01-17 14:13   ` Bharathi Subramanian
2006-01-17 14:52     ` Kevin D. Kissell
2006-01-17 15:28       ` Bharathi Subramanian
2006-01-27  8:32       ` Bharathi Subramanian
2006-01-30 18:54         ` /dev/cpuid or /proc/cpuinfo Philip Mucci
2006-02-01 11:30           ` Ralf Baechle [this message]

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=20060201113006.GA3562@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=linux-mips@linux-mips.org \
    --cc=mucci@cs.utk.edu \
    /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: link
Be 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.