Re: better cpu throttling

2010-06-30 Thread Tobias Weingartner
On Wednesday, June 30, Darrin Chandler wrote: > > What you're saying is true, but that's not the only use case. Streaming > media may not benefit from 100% cpu but may not be able to work properly > at 0%. The same goes for other common tasks as well. Running at 30% or > 50% will indeed save power

GRATIS!!! Revit - Control-P - MS Project (Utilice CREDITO FISCAL para Capacitarse)

2010-06-30 Thread ESEADE - NAyC (SEPyME) )
Para Verlo en la WEB Que es el progreama de cridito fiscal para capacitacisn? Es un programa por intermedio del cual las empresas constructoras y estudios de arquitectura de todo el pams que cumplan con los req

Re: better cpu throttling

2010-06-30 Thread Darrin Chandler
On Wed, Jun 30, 2010 at 11:44:46PM +0200, Peter Hessler wrote: > On 2010 Jun 30 (Wed) at 22:25:45 +0100 (+0100), Luis Henriques wrote: > :Eventually there are usage scenarios where setting the maximum > :performance to 50% (or whatever value) may make sense -- if you want to > :save some power, for

Re: better cpu throttling

2010-06-30 Thread Luis Henriques
On Wed, Jun 30, 2010 at 04:08:17PM -0600, Theo de Raadt wrote: > > Eventually there are usage scenarios where setting the maximum > > performance to 50% (or whatever value) may make sense -- if you want to > > save some power, for example. Anyway, I was just trying to make sure > > everyone unders

Re: better cpu throttling

2010-06-30 Thread Theo de Raadt
> On Wed, Jun 30, 2010 at 01:46:55PM -0600, Theo de Raadt wrote: > > > For example, if I am compiling the kernel, my laptop will overheat and > > > shutdown. So, I need to run apm -L in order to keep the temperature > > > lower. > > > > Balony. What you are facing is that the acpi throttling cod

Re: better cpu throttling

2010-06-30 Thread Peter Hessler
On 2010 Jun 30 (Wed) at 22:25:45 +0100 (+0100), Luis Henriques wrote: :Eventually there are usage scenarios where setting the maximum :performance to 50% (or whatever value) may make sense -- if you want to :save some power, for example. It doesn't really save any power. I've done tests while doi

Re: better cpu throttling

2010-06-30 Thread Luis Henriques
On Wed, Jun 30, 2010 at 01:46:55PM -0600, Theo de Raadt wrote: > > For example, if I am compiling the kernel, my laptop will overheat and > > shutdown. So, I need to run apm -L in order to keep the temperature > > lower. > > Balony. What you are facing is that the acpi throttling code is not > h

Re: IO sorting

2010-06-30 Thread Kenneth R Westerback
On Wed, Jun 30, 2010 at 01:55:30PM -0500, Marco Peereboom wrote: > New drives have much more sophisticated IO queueing algorithms and > posses much more information about the physical limitations of drive > platters (or lack thereof) than an OS can ever hope to have. So switch > SCSI (and SATA) dr

Re: better cpu throttling

2010-06-30 Thread Darrin Chandler
On Wed, Jun 30, 2010 at 03:34:14PM -0400, Ted Unangst wrote: > On Wed, Jun 30, 2010 at 3:23 PM, Luis Henriques > wrote: > > Probably, a silly question, but here it goes: > > > > With this patch, I will not be able to set the perflevel to, say, 50% and > > keep the system using that performance lev

Re: better cpu throttling

2010-06-30 Thread Theo de Raadt
> For example, if I am compiling the kernel, my laptop will overheat and > shutdown. So, I need to run apm -L in order to keep the temperature > lower. Balony. What you are facing is that the acpi throttling code is not handling your laptop fast enough. It is unrelated to the problem that tedu

Re: better cpu throttling

2010-06-30 Thread Luis Henriques
On Wed, Jun 30, 2010 at 03:34:14PM -0400, Ted Unangst wrote: > On Wed, Jun 30, 2010 at 3:23 PM, Luis Henriques wrote: > > Probably, a silly question, but here it goes: > > > > With this patch, I will not be able to set the perflevel to, say, 50% and > > keep the system using that performance level

Re: better cpu throttling

2010-06-30 Thread Ted Unangst
On Wed, Jun 30, 2010 at 3:23 PM, Luis Henriques wrote: > Probably, a silly question, but here it goes: > > With this patch, I will not be able to set the perflevel to, say, 50% and > keep the system using that performance level forever. Is this correct? > I guess that with current apmd we are abl

Re: better cpu throttling

2010-06-30 Thread Luis Henriques
Probably, a silly question, but here it goes: With this patch, I will not be able to set the perflevel to, say, 50% and keep the system using that performance level forever. Is this correct? I guess that with current apmd we are able to do this. If both of these two statements are true (maybe th

Re: IO sorting

2010-06-30 Thread Thordur I Bjornsson
On Wed, Jun 30, 2010 at 01:55:30PM -0500, Marco Peereboom wrote: > New drives have much more sophisticated IO queueing algorithms and > posses much more information about the physical limitations of drive > platters (or lack thereof) than an OS can ever hope to have. So switch > SCSI (and SATA) dr

IO sorting

2010-06-30 Thread Marco Peereboom
New drives have much more sophisticated IO queueing algorithms and posses much more information about the physical limitations of drive platters (or lack thereof) than an OS can ever hope to have. So switch SCSI (and SATA) drives to use the shiny new bufq that does not sort IOs. Essentially this k

Re: better cpu throttling

2010-06-30 Thread Mark Kettenis
> Date: Wed, 30 Jun 2010 14:32:26 -0400 (EDT) > From: Ted Unangst > > I like this one better. Slow down the poll interval just a little so it's > not so hysterical, but also go straight to 100. If you need CPU, you need > CPU. It still backs down slowly, but that's just to prevent getting >

better cpu throttling

2010-06-30 Thread Ted Unangst
I like this one better. Slow down the poll interval just a little so it's not so hysterical, but also go straight to 100. If you need CPU, you need CPU. It still backs down slowly, but that's just to prevent getting caught in slow mode again. It also pays attention to per-core load, much be

Re: kernel cpu perf tuning

2010-06-30 Thread Martin Toft
On Tue, Jun 29, 2010 at 11:57:00PM -0400, Ted Unangst wrote: > Here's a first cut at throwing some code into the kernel. You'll > definitely want to kill apmd if you're running it. It's rather rough, in > the wrong spot, and so on, but it's a place to start for further hacking. > I'm not conv