lkml.org 
[lkml]   [1998]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Cyrix setup
On Sun, 8 Mar 1998, Phil Brutsche wrote:

> Ah... sorry, but no. What would happen if someone would use some of
> those performace-enhancing options in the intitialization of the kernel?
> Either:
> a) They would work great and the kernel would be super fast
> or
> b) They wouldn't work at all and would completely mess things up (lock
> the machine, interfere with HD operation, I can't recall what the points
> where against doing this during the last discussion).

This should be a technical problem not a political one. Rather than
looking at the opinions that have been expressed you need to look
at the facts. Questions: Do you know what the default state of a
6x86 is at power up? Do you consider this state to be satisfactory
or could a different state be better?

The general aim should be to have Linux running in the optimal
safe state by default. I do not consider running with suspend on
halt off to satisfy that. With it off you run greater risks of
cooking the CPU if the CPU fan fails (the most common hardware
failure today - and a cooked CPU usually exhibits "occasional",
"strange" behaviour...). With it off you are using unnecessary
power. For an organization with desk loads of, mostly idle PCs,
this is a measurable cost (not to mention an additional burden
on air conditioning leading to knock on, but less measurable,
costs). It's also an environmental no-no. These days environmental
groups would like us to stop leaving our TVs on stand by and
switch them off at the wall. Running a modern CPU with no suspend
on halt enabled is more like leaving a small TV *on* :-).

Back when I did the non-Intel (nee Cyrix) patch I seem to
remember a few reports that some options seemed to cause problems
on a handful of motherboards - but then many things have trouble
on the odd few junk motherboards. I don't remember anyone having
problem serious enough to stop them booting. Which brings us
on to the next point:

> Besides, what if someone wanted to CHANGE those options? They would have
> to re-compile their kernel every time. It's so much more convenient to
> have the initializations in a user-space program.

Rubbish! You've just answered your own point. If people find they
don't want the optimal, safe settings they can use something like
set6x86 to change them.

Currently we have a situation where the majority *should* be
changing settings with set6x86. We should have a situation where
the majority should not need to worry about it. Why should even
a system administrator need to know about proprietery settings
of specific CPUs? They shouldn't. Bottom line.

Mike

P.S. If you are worried about adding a few bytes of code to change
the settings (which only needs to be done at boot so it could be
in the init segment) then you would do better to worry about the
tables of CPU type description people seem to like adding (which,
IMHO, tend to be somewhat over specific and which are needed
thoughout uptime)

--
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site