Stealing ur megahurts (no, really)
From: John Richard Moser
Date: Fri May 19 2006 - 02:17:25 EST
-----BEGIN PGP SIGNED MESSAGE-----
I saw someone bench Windows XP on a 66MHz CPU with 20MB RAM (Pentium
clocked down), and had an interesting thought.. try to bear with me on
Often times software engineers will seek out old machines, like 486DX
based or Pentium Pro or whatnot, whatever they can find. This is
because of something apparently called "Requirements Engineering," which
a colleague of mine explained to me as a bunch of programming students
stopping by his dorm to use his slow ass machine so they can figure out
what the "Minimum System Requirements" for their projects should be.
Scrambling for an old machine is ridiculous. Down-clocking makes sense
because you can adjust to varied levels; but it's difficult and usually
infeasible. Pulling memory and mix and matching is not much better.
On Linux we have mem= to toy with memory, which I personally HAVE used
to evaluate how various distributions and releases of GNOME operate
under memory pressure. This is a lot more convenient than pulling chips
and trying to find the right combination. This option was, apparently,
designed for situations where actual system memory capacity is
mis-detected (mandrake 7.2 and its insistence that a 256M memory stick
is 255M....); but is very useful in this application too.
This brings the idea of a cpumhz= parameter to adjust CPU clock rate.
Obviously we can't do this directly, as convenient as this would be; but
the idea warrants some thought, and some thought I gave it. What I came
up with was simple: Adjust time slice length and place a delay between
time slices so they're evenly spaced.
The idea here would be to determine first the ratio of CPU real MHz to
target MHz and use that for adjustment. We need to calculate a number
of things to do this:
- The normal length of a time slice, in mS. I believe this is 20mS.
- The normal number of time slices per second. This should be 50.
- The ratio of real_mhz to target_mhz
- The new length of a time slice, (target_mhz/real_mhz) * 20mS
- The spacing between time slices, 20 - time_slice (*)
(*) (1000mS - (time_slice * time_slices)) / time_slices
== 1000mS/time_slices - ((time_slice*time_slices) / time_slices)
== 1000/time_slices - time_slice
== 20 - time_slice WHERE time_slices = 20 per second
What this means is the scheduler sits idle between time slices, and uses
shorter time slices that reflect what a full time slice would have time
to do on a lower clocked CPU. This of course isn't perfect, but it's near.
A modern 2GHz CPU with cpumhz=200 would result in the following data:
time_slice = 2mS
time_slices = 50 per second
delay_between_slices = 18mS
This should be sufficient that 1/10 the time (2 of 20mS) is allotted to
a time slice; and the CPU wastes 9/10 of the time idle. This would
somewhat simulate a 200MHz system. Probably not very well though.
Questions? Comments? Particular ideas on what would happen?
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
-- Bosc, Evil alien overlord from the fifth dimension
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/