On Tue, Nov 29, 2005 at 09:19:31AM -0500, Steven Rostedt wrote:
> > And in practice the CPU will run so hot that only benchmarkers like it.
>
> Why would it run hot? What's the difference between polling and doing
> other things. How many transistors does it take to poll?
It will prevent the CPU from going into sleep states and essentially
keep most of it enabled.
>
> >
> > I think switching idle is the wrong way to do. We should rather
> > fix the various problems.
> >
> > For fixing the TSC issue it is 100% the wrong approach Imho.
>
> I would only say 80% the wrong approach, but that's me ;-)
>
> > Basically software has to live with TSCs being unsynchronized
> > and gettimeofday should do the right thing (and if not it should be fixed)
>
> I guess the biggest complaint most have is that the rdtsc _is_ the
> fastest way to read a clock. If it isn't reliable, then what good is
It's the fastest way to read something which needs quite complex
knowledge to turn into a reliable clock value. In general only
the kernel has this knowledge.
And gettimeofday is optimized to give you the fatest reliable
clock.
> it? It's unfortunate that Intel didn't solidify the clock usage. Yes,
> use HPET, or something else, but those are slower, and may not be on all
> systems. Every system that I owned had a tsc but for critical systems
> it isn't up to par (what a shame).
Just use gettimeofday. It shields you from all that and when
the hardware supports it is quite fast too.
> > > system has been idle for some time. E.g. cpufreqd could sample idle time
> > > and turn on/off idle=poll. High-performance setups could enable it all
> > > the time.
> >
> > And upgrade their server air condition or issue additional ear protection
> > to the desktop user? Most likely you will just drive the CPUs into
> > thermal throttle at some point with that, not get more performance anyways.
>
> Again, what would make it so hot? It is a waste of CPU cycles, and does
> waste energy that way, but does it really heat up the CPU that much?
Yes it does.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
