number and freq of CPUs

number and freq of CPUs

Post by Joachim Worringe » Sat, 08 Jan 2000 04:00:00



I need to know how many CPUs are running and at which clock frequency. I
know that this information is accessable via /proc/cpuinfo, but I do not
want to parse a text file to get this simple information (in my
library). Under Solaris, I use the processor_info() function - is there
something similar under Linux?

 thanks, Joachim

--
|  _      |  Joachim Worringen
|_|_`__   |  Lehrstuhl fuer Betriebssysteme, RWTH Aachen
  | |__)  |  http://www.lfbs.rwth-aachen.de/~joachim

 
 
 

number and freq of CPUs

Post by Friedrich Seifer » Sat, 08 Jan 2000 04:00:00



> I need to know how many CPUs are running and at which clock frequency. I
> know that this information is accessable via /proc/cpuinfo, but I do not
> want to parse a text file to get this simple information (in my
> library). Under Solaris, I use the processor_info() function - is there
> something similar under Linux?

>  thanks, Joachim

AFAIK there is no such function in Linux.
But you could let grep & Co. do the parsing.

Try
        fd = popen("/bin/cat /proc/cpuinfo|grep MHz|wc|cut -b 7");
        /* now read the number of processors (in ASCII code) from fd */
and
        fd = popen("/bin/cat /proc/cpuinfo|grep MHz|cut -b 12-");
        /* read frequencies from fd (separated by "\n") */

Okay, it's not very elegant, but it works (at least as long as the
format of /proc/cpuinfo doesn't change to much).

Bye, Friedrich

 
 
 

number and freq of CPUs

Post by Joachim Worringe » Tue, 11 Jan 2000 04:00:00




> > I need to know how many CPUs are running and at which clock frequency. I
> > know that this information is accessable via /proc/cpuinfo, but I do not
> > want to parse a text file to get this simple information (in my
> > library). Under Solaris, I use the processor_info() function - is there
> > something similar under Linux?

> >  thanks, Joachim

> AFAIK there is no such function in Linux.
> But you could let grep & Co. do the parsing.

> Try
>         fd = popen("/bin/cat /proc/cpuinfo|grep MHz|wc|cut -b 7");
>         /* now read the number of processors (in ASCII code) from fd */
> and
>         fd = popen("/bin/cat /proc/cpuinfo|grep MHz|cut -b 12-");
>         /* read frequencies from fd (separated by "\n") */

> Okay, it's not very elegant, but it works (at least as long as the
> format of /proc/cpuinfo doesn't change to much).

Come on - that's ridicolous! The /proc fs *has* changed ever so often,
and it will probably continue to change. And it is not consistent across
different hardware platforms.

The Linux Kernel-API has to become much more stable to be considered a
serious and maintainable platform - I do *not* like to develop low-level
libraries for it, because most of the time I have deal with problems and
changes introduced with new kernel releases.

 Joachim

--
|  _      |  Joachim Worringen
|_|_`__   |  Lehrstuhl fuer Betriebssysteme, RWTH Aachen
  | |__)  |  http://www.lfbs.rwth-aachen.de/~joachim

 
 
 

number and freq of CPUs

Post by Joachim Worringe » Tue, 11 Jan 2000 04:00:00



> If you manage to evolve something truly useful against that
> background (such as realvideo or better) then they maybe might
> bend a few inches to help you, but not that much.

I hope I understand your sarcasm as you ment it... Anyway: if Linux is
designed for realvideo, then good-bye. But I don't thinks so.

Quote:> Bottom line: they are not there for your convenience. There is nobody
> to complain to. It's evolutionary anarchy at work, evolving both sides
> of the competition. Nobody is going to hold things steady for you.
> Learn to adapt, and adapt fast. Write maintainable and adaptable code.

You mean: write code that automatically detects bugs and
incompatibilities which are introduced with new kernels? I surely won't.
This has nothing to do with "learning to adapt". The kernel maintainers
need to learn to ensure at least a certain degree of reliability.

Otherwise, I might just stick to Solaris which offers everything Linux
has and more - and without the problems described.

 Joachim

--
|  _      |  Joachim Worringen
|_|_`__   |  Lehrstuhl fuer Betriebssysteme, RWTH Aachen
  | |__)  |  http://www.lfbs.rwth-aachen.de/~joachim

 
 
 

number and freq of CPUs

Post by Peter T. Breue » Tue, 11 Jan 2000 04:00:00


: Come on - that's ridicolous! The /proc fs *has* changed ever so often,
: and it will probably continue to change. And it is not consistent across
: different hardware platforms.

: The Linux Kernel-API has to become much more stable to be considered a
: serious and maintainable platform - I do *not* like to develop low-level

We live in a brave new world.  The paradigm is - keep adapting your
code to the shifting sands under you.  It's an evolutionary competetion.
The kernel developers are your enemy, not your friend. You have to
turn truly big guns on them to make them do something for YOU, such
as maintain an interface that they merely deigned to make available
for you (if you don't like the one they gave you, patch their code).

If you manage to evolve something truly useful against that
background (such as realvideo or better) then they maybe might
bend a few inches to help you, but not that much.

Bottom line: they are not there for your convenience. There is nobody
to complain to. It's evolutionary anarchy at work, evolving both sides
of the competition. Nobody is going to hold things steady for you.
Learn to adapt, and adapt fast. Write maintainable and adaptable code.

Peter

 
 
 

number and freq of CPUs

Post by Peter T. Breue » Tue, 11 Jan 2000 04:00:00



:> If you manage to evolve something truly useful against that
:> background (such as realvideo or better) then they maybe might
:> bend a few inches to help you, but not that much.

: I hope I understand your sarcasm as you ment it... Anyway: if Linux is

It's not sarcasm, in this case! I mean it.

: designed for realvideo, then good-bye. But I don't thinks so.

Realvideo was the first example of somthing quite useful that comes to
mind.

:> Bottom line: they are not there for your convenience. There is nobody
:> to complain to. It's evolutionary anarchy at work, evolving both sides
:> of the competition. Nobody is going to hold things steady for you.
:> Learn to adapt, and adapt fast. Write maintainable and adaptable code.

: You mean: write code that automatically detects bugs and
: incompatibilities which are introduced with new kernels? I surely won't.

I didn't say that. I said write at the level at which you can maintain
the code well in the face of changes. If you parse proc output
make sure that you use a liberal parser and make sure that you code
the patterns expected and grabbed in an array of constants. Don't
write some labyrinthine state machine.

: This has nothing to do with "learning to adapt". The kernel maintainers
: need to learn to ensure at least a certain degree of reliability.

They need to learn nothing. Applications aren't their area of
interest.

: Otherwise, I might just stick to Solaris which offers everything Linux
: has and more - and without the problems described.

Good. Goodbye. You just got out-evolved. (Solaris is a fleapit to
program for).

Peter

 
 
 

number and freq of CPUs

Post by Friedrich Seifer » Thu, 13 Jan 2000 04:00:00



> Come on - that's ridicolous! The /proc fs *has* changed ever so often,
> and it will probably continue to change.

Well, maybe it's a bit awkward, but it's not ridiculous. There are a
number of programs around that get their data from the /proc fs (ps,
top, xosview,...), and no one complains that they have to be updated
with new kernels.

Quote:> And it is not consistent across different hardware platforms.

Okay, I didn't consider that. /proc/cpuinfo is probably one of the most
architecture dependent one. /proc/stat seems to be much more generic. It
contains the number of cpus, but not their frequency.

Anyway, reading the /proc fs was just my first idea for the problem.
Another one was to write a small kernel module that reads the internal
data structures and returns it via read or ioctl. But I'm afraid you
won't like that neither.

Actually it shouldn't be a problem to introduce a syscall like Solaris'
processor_info(). Would someone like to write a patch?

Quote:> The Linux Kernel-API has to become much more stable to be considered a
> serious and maintainable platform - I do *not* like to develop low-level
> libraries for it, because most of the time I have deal with problems and
> changes introduced with new kernel releases.

On the one hand it's very positiv that the kernel is being improved on
and on. However, as I am developing drivers for Linux I'm sometimes not
too happy about that, because I can hardly keep pace with the kernel
developers.
But I think, we just have to live with it, if we want to use an OS that
is maintained by a community and not by a company.

Bye, Friedrich

 
 
 

number and freq of CPUs

Post by Joachim Worringe » Thu, 13 Jan 2000 04:00:00



> Anyway, reading the /proc fs was just my first idea for the problem.
> Another one was to write a small kernel module that reads the internal
> data structures and returns it via read or ioctl. But I'm afraid you
> won't like that neither.

Would be better, but I need my software to run on standard kernels.

Quote:> Actually it shouldn't be a problem to introduce a syscall like Solaris'
> processor_info(). Would someone like to write a patch?

I'd like to, but I don't know how to submit such a patch.

Quote:> On the one hand it's very positiv that the kernel is being improved on
> and on. However, as I am developing drivers for Linux I'm sometimes not
> too happy about that, because I can hardly keep pace with the kernel
> developers.
> But I think, we just have to live with it, if we want to use an OS that
> is maintained by a community and not by a company.

Sure, but I think there's only a small number of persons who decide
about the kernel - they should keep kernel API and functionality
consistent at least throughout the stable sub-releases (2.2.x, i.e.).
Ohter problems I have (with shared memory) vary from 2.2.5 to 2.2.10 and
2.2.12. I'll post these on occasion...

 Joachim

--
|  _      |  Joachim Worringen
|_|_`__   |  Lehrstuhl fuer Betriebssysteme, RWTH Aachen
  | |__)  |  http://www.lfbs.rwth-aachen.de/~joachim

 
 
 

number and freq of CPUs

Post by Friedrich Seifer » Fri, 14 Jan 2000 04:00:00



> > Actually it shouldn't be a problem to introduce a syscall like Solaris'
> > processor_info(). Would someone like to write a patch?

> I'd like to, but I don't know how to submit such a patch.

I've never done it myself so far, but section 9 of the Linux Kernel
Hacking HOWTO (http://www.samba.org/~netfilter/kernel-hacking-HOWTO/)
describes the administrative work needed to get something into the
kernel.

Quote:> Ohter problems I have (with shared memory) vary from 2.2.5 to 2.2.10 and
> 2.2.12. I'll post these on occasion...

Yes, please do it.

Bye, Friedrich

 
 
 

1. PCI bus freq with CPU freq at (X * 40)Mhz?


: Sorry for ignorance, but what will be the frequency on a PC's PCI bus
: when the CPU runs at main frequency of 40MHz (DX2/80, DX4/120 i.e.)?

: I always thought that PCI will than run at 40MHz too.
: But was told today that it will be only 20MHz?!  Oh God.
: How can I check this for sure, without running hated benchmarks,
: but only by exploration of MB jumpers?

PCI is specified to run at up to 33MHz.  To accomodate faster CPU
clocks motherboards can provide the facility for PCI to run at
some fraction of the CPU.  My motherboard (GA-486AMS) allows a
CPU:PCI ratio of 1:1 or 2:1, configured in the BIOS setup.  In
principle other ratios could be used (e.g. 4:3), but I'm not aware
of any motherboards which support this.

Having said that, I have run PCI at 40MHz with a DX4-120, and it
worked (with AHA-2940 and S3-968).  This made little or no difference
to kernel build times compared to 20MHz, although this is a crude
benchmark.  Doing this could reduce the life expectancy of PCI
cards.

(A recent version of the PCI spec (2.1?) allows for faster clocks,
but I don't think there are many compliant cards available).

: I was also told that having 40MHz will probably cause
: an addition of extra wait states for cache and RAM access,
: thus making a box considerably _slower_ for real work
: than with 33MHz CPU main frequency, especially for UNIX-like OS
: (FreeBSD in my case, but who cares).  Any comments on this one?

With 15ns cache and 70ns SIMMs I was able to run a DX4-120 with
0WS and 2-1-1-1 cache burst read, the fastest settings supported.
This is probably motherboard dependent.

: And, in case both statements are true, why bother looking
: at (X * 40)MHz 486 CPUs at all?

They are more of a win with VLB motherboards.

: P.S. I don't own a PCI box, but just planning to buy one, choosing
:      the best bang-per-buck configuration now.
:      Was considering AMD 160MHz (glorified 486, called 5x86, he-he :)
:      chip, which has 40MHz main freq and 4x multiplier.

This is the 5x86-133, it's only 160MHz if you overclock it, and then you're
back where you started...

:      Now I'm seriously considering AMD 133 part (this one is 33MHz, 4x).
:      Guys have a very nice opinions on it.

For PCI, the AMD 5x86-133 makes more sense.  I'm running one now,
and very happy with it.

iain

2. PGP - Anyone w/ success compiiling? Suggestions?

3. Rs/6000 CPU type and CPU number

4. Linux Printing HOWTO (part 1/2)

5. 2.5.64 - cpu freq not turned on

6. SUMMARY: One handed computing for disabled person [in misc.handicap]

7. Hotplug CPU prep IV: non-linear CPU numbers

8. mklinux question

9. determining CPU freq of Sun Sparc 10?

10. Hotplug CPU prep V: x86 non-linear CPU numbers

11. Matrox Mystique ands X.

12. Sun license manager...1%cpu...1%cpu...50%cpu50%cpu50%cpu....

13. Number Nine....Number Nine....Number Nine