Re: cpufreq and changing driver
Marco Calviani wrote: Hi Nate, 2005/11/30, Nate Lawson <[EMAIL PROTECTED]>: You should send the full output of "sysctl dev.cpu". There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 1800/24000 1600/2 1400/18000 1225/15750 1050/13500 1000/16000 875/14000 750/12000 625/1 600/12000 525/10500 450/9000 375/7500 300/6000 225/4500 150/3000 75/1500 hi, may i just ask what are the numbers after slash(es) in freq_levels ? (sysctl -d does not say anything but "dev.cpu.0.freq_levels: CPU frequency levels") (and i've got -1 everywhere (??); machine is pentium-m 755) cheers, martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi list, 2005/12/2, Bruno Ducrot <[EMAIL PROTECTED]>: I don't see why you can't run powerd more frequently, I do.. Unless your ACPI has a problem that means the transition is slow. I'm sure this could not be done under Linux without a lot of problems (it is required to use the /proc things and it's too slow in that case). I can't imagine that doing 5 (or even 50) syscalls a second is a big CPU load unless there is a specific problem with sysctls or the cpufreq infrastructure. If that's possible being not so intrusive with, say 50 syscalls under FreeBSD, then all I said above is indeed stupid crap. I run powerd like this -> /usr/sbin/powerd -i 90 -r 30 -a adaptive -b adaptive -n adaptive -p 200 Well, i've tried decreasing the polling interval, but there is an increased powerd cpu load: at 100ms polling interval the cpu load is to an astonishing 20% circa, which i think it's too much for a normal use. The sampling rate with ondemand governor in linux kernel is 10ms but cpufreqd is at 0.6% on average cpu load. powerd is not intended to do high speed polling. If you do that, your system will almost never be idle and so we can't save power via Cx. We don't need high speed sampling right now, we need a predictive algorithm. So until someone implements this, it's moot. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi Nate, 2005/12/2, Nate Lawson <[EMAIL PROTECTED]>: > This work is easy, it's just grunt work implementing and testing to see > which is best. See this page for details on how to proceed: > > http://wikitest.freebsd.org/moin.cgi/powerd > > Wikitest seems to be down so here's the text only: > http://66.102.7.104/search?q=cache:IEXV5nW17ZMJ:wikitest.freebsd.org/moin.cgi/powerd+site:wikitest.freebsd.org+powerd+&hl=en&lr=&strip=1 > I'll have a look at it whenever it will become online again. Regards, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi list, 2005/12/2, Bruno Ducrot <[EMAIL PROTECTED]>: > > I don't see why you can't run powerd more frequently, I do.. Unless your > > ACPI > > has a problem that means the transition is slow. > > I'm sure this could not be done under Linux without a lot of > problems (it is required to use the /proc things and it's too slow in > that case). > > > I can't imagine that doing 5 (or even 50) syscalls a second is a big CPU > > load > > unless there is a specific problem with sysctls or the cpufreq > > infrastructure. > > If that's possible being not so intrusive with, say 50 syscalls under FreeBSD, > then all I said above is indeed stupid crap. > > > I run powerd like this -> > > /usr/sbin/powerd -i 90 -r 30 -a adaptive -b adaptive -n adaptive -p 200 > > Well, i've tried decreasing the polling interval, but there is an increased powerd cpu load: at 100ms polling interval the cpu load is to an astonishing 20% circa, which i think it's too much for a normal use. The sampling rate with ondemand governor in linux kernel is 10ms but cpufreqd is at 0.6% on average cpu load. Regards, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Fri, Dec 02, 2005 at 08:35:54PM +1030, Daniel O'Connor wrote: > On Fri, 2 Dec 2005 19:35, Marco Calviani wrote: > > > It's not present under powerd for the simple fact that to be efficient > > > in term of not being too intrusive (kernel to user data transfers, etc), > > > powerd can only provide a limited number of check per second (at this > > > time, 2 per second). But the current algorithm present in powerd is > > > not well suited in that case. You have to wait one demi-second > > > for the processor being put to full speed if the system was idle > > > before. > > > > Are there on the horizon any sort of plans to implement a newer and > > more efficient algorithm to increase the number of transition per > > second? Sorry but i've not understood why linux-cpufreqd is able to > > cope with those without being so intrusive. > > I don't see why you can't run powerd more frequently, I do.. Unless your ACPI > has a problem that means the transition is slow. I'm sure this could not be done under Linux without a lot of problems (it is required to use the /proc things and it's too slow in that case). > I can't imagine that doing 5 (or even 50) syscalls a second is a big CPU load > unless there is a specific problem with sysctls or the cpufreq > infrastructure. If that's possible being not so intrusive with, say 50 syscalls under FreeBSD, then all I said above is indeed stupid crap. > I run powerd like this -> > /usr/sbin/powerd -i 90 -r 30 -a adaptive -b adaptive -n adaptive -p 200 > -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Fri, 2 Dec 2005 19:35, Marco Calviani wrote: > > It's not present under powerd for the simple fact that to be efficient > > in term of not being too intrusive (kernel to user data transfers, etc), > > powerd can only provide a limited number of check per second (at this > > time, 2 per second). But the current algorithm present in powerd is > > not well suited in that case. You have to wait one demi-second > > for the processor being put to full speed if the system was idle > > before. > > Are there on the horizon any sort of plans to implement a newer and > more efficient algorithm to increase the number of transition per > second? Sorry but i've not understood why linux-cpufreqd is able to > cope with those without being so intrusive. I don't see why you can't run powerd more frequently, I do.. Unless your ACPI has a problem that means the transition is slow. I can't imagine that doing 5 (or even 50) syscalls a second is a big CPU load unless there is a specific problem with sysctls or the cpufreq infrastructure. I run powerd like this -> /usr/sbin/powerd -i 90 -r 30 -a adaptive -b adaptive -n adaptive -p 200 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpIsUmSjEcrk.pgp Description: PGP signature
Re: cpufreq and changing driver
Marco Calviani wrote: Hi Bruno, > > 2) sorry what about the point that we were discussing above? The high number of transition you were explaining me, are present in the actual implementation of powerd, and if not, why? It's not present under powerd for the simple fact that to be efficient in term of not being too intrusive (kernel to user data transfers, etc), powerd can only provide a limited number of check per second (at this time, 2 per second). But the current algorithm present in powerd is not well suited in that case. You have to wait one demi-second for the processor being put to full speed if the system was idle before. Are there on the horizon any sort of plans to implement a newer and more efficient algorithm to increase the number of transition per second? Sorry but i've not understood why linux-cpufreqd is able to cope with those without being so intrusive. This work is easy, it's just grunt work implementing and testing to see which is best. See this page for details on how to proceed: http://wikitest.freebsd.org/moin.cgi/powerd Wikitest seems to be down so here's the text only: http://66.102.7.104/search?q=cache:IEXV5nW17ZMJ:wikitest.freebsd.org/moin.cgi/powerd+site:wikitest.freebsd.org+powerd+&hl=en&lr=&strip=1 -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi Bruno, > > 2) sorry what about the point that we were discussing above? The high > > number of transition you were explaining me, are present in the actual > > implementation of powerd, and if not, why? > > It's not present under powerd for the simple fact that to be efficient > in term of not being too intrusive (kernel to user data transfers, etc), > powerd can only provide a limited number of check per second (at this > time, 2 per second). But the current algorithm present in powerd is > not well suited in that case. You have to wait one demi-second > for the processor being put to full speed if the system was idle > before. > Are there on the horizon any sort of plans to implement a newer and more efficient algorithm to increase the number of transition per second? Sorry but i've not understood why linux-cpufreqd is able to cope with those without being so intrusive. Best regards, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 01:57:42PM -0800, Nate Lawson wrote: > Marco Calviani wrote: > >Hi Bruno, > > > >Yes cpufreq is loaded at boot time in /boot/loader.conf .However i > >don't know how to tell him that i want to load est instead of > >acpi_perf. > > est is preferred if supported. But probably est doesn't have a table > for his processor so acpi_perf is used. That's the case for any Dothan IIRC. > There's nothing wrong with > using acpi_perf -- it just gives a BIOS interface to est anyway. indeed. > > You can test this with: > hint.acpi_perf.0.disabled="1" > > This will cause acpi_perf to let est attach. But I suspect est won't. est need acpi_perf if a dothan or above is in use... On the other hand, the linux driver work for the OP, and that's not acceptable we can't do the same :) Maybe a link to a 'acpidmp -d -t' may help to see a little deeper? Marco, could you send to me privately or better provide a link to this output? Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi Bruno, 2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>: Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. est is preferred if supported. But probably est doesn't have a table for his processor so acpi_perf is used. There's nothing wrong with using acpi_perf -- it just gives a BIOS interface to est anyway. You can test this with: hint.acpi_perf.0.disabled="1" This will cause acpi_perf to let est attach. But I suspect est won't. -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi Bruno, 2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>: > Did you load the cpufreq driver at boot time which include the est > driver as said before? It will replace the acpi_perf if appropriate. > > -- > Bruno Ducrot Yes cpufreq is loaded at boot time in /boot/loader.conf .However i don't know how to tell him that i want to load est instead of acpi_perf. Regards, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 08:05:59PM +, Marco Calviani wrote: > Hi Nate, > > 2005/11/30, Nate Lawson <[EMAIL PROTECTED]>: > > > > > You should send the full output of "sysctl dev.cpu". There is no > > cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look > > at your dmesg to see if one is probing/attaching. > > > > > sysctl dev.cpu > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.CPU0 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.freq: 1000 > dev.cpu.0.freq_levels: 1800/24000 1600/2 1400/18000 1225/15750 > 1050/13500 1000/16000 875/14000 750/12000 625/1 600/12000 > 525/10500 450/9000 375/7500 300/6000 225/4500 150/3000 75/1500 > > > > If you are using acpi and load cpufreq.ko, you've got all the cpufreq > > drivers in one package. The right one for your platform will > > automatically probe/attach. > > > It seems that my system has recognized acpi_perf as the appropriate > driver. But since my CPU is a dothan type centrino i would like to > understand why is not possible to use the est driver. Did you load the cpufreq driver at boot time which include the est driver as said before? It will replace the acpi_perf if appropriate. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 12:23:52PM -0800, Nate Lawson wrote:
> Bruno Ducrot wrote:
> >On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
> >
> >>Marco Calviani wrote:
> >>
> >>>Hi,
> >>>
> >>>2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>:
> >>>
> >>>
> You have to load the cpufreq.ko module at boot.
> Adding that line:
> cpufreq_load = "YES"
> to /boot/loader.conf
> should be OK.
> >>>
> >>>
> >>>I have that line in that position, and it seems working. The point is
> >>>that i would like to change the driver and use (AFAIU) a better driver
> >>>for my system (est).
> >>>In particular i have:
> >>>
> >>>dev.cpu.0.%desc: ACPI CPU
> >>>dev.cpu.0.%driver: cpu
> >>>dev.cpu.0.%location: handle=\_PR_.CPU0
> >>>dev.cpu.0.%pnpinfo: _HID=none _UID=0
> >>>dev.cpu.0.%parent: acpi0
> >>>
> >>>Maybe i didn't understood well: but what i have to do to use the Intel
> >>>Enhanced SpeedStep driver?
> >>
> >>You should send the full output of "sysctl dev.cpu". There is no
> >>cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
> >>at your dmesg to see if one is probing/attaching.
> >>
> >>If you are using acpi and load cpufreq.ko, you've got all the cpufreq
> >>drivers in one package. The right one for your platform will
> >>automatically probe/attach.
> >>
> >>
> powerd need some rework in order to get it working properly. There
> is one FreeBSD project on that subject if you are interrested.
> >>>
> >>>Well, thanks i'm very interested, although i'm not at all experienced
> >>>in kernel programming
> >>>
> >>>I'm not inside this issue, but it would not be possible to "emulate"
> >>>the behaviour of the ondemand governor? (sorry if this question makes
> >>>no sense)
> >>
> >>I have no idea what you mean by "on-demand governor". The only
> >>automated control of cpu speed is either by the BIOS (which we can't
> >>control) or the TM/TM2 (and that one is heat-based, not load-based).
> >>
> >
> >
> >The ondemand governor is basically an implemation of the following
> >algorithm:
> >
> >There is a counter, say count.
> >
> >at each given fixed intervall:
> >if (idle less than a watermark) {
> >frequency full
> >reinitialise count to 10
> >} else if (idle more than another watermark) {
> >decrement count
> >if count is 0 {
> >down one step the frequency
> >}
> >else reinitilize count to 10
> >
> >
> >Note that in the latter case, the down step is performed only
> >after 10 such comparison. In other word, intervall is ten times
> >larger for the down side than the full frequency one.
> >
> >This work well when you can perform, say, 20 to 50 transitions per
> >second. Otherwise, it is pretty bad.
> >
>
> Send me a URL to the datasheet that says Intel implemented this.
http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y
> That algorithm is basically what powerd does. So just run powerd.
Indeed.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi Bruno,
> The ondemand governor is basically an implemation of the following
> algorithm:
>
> There is a counter, say count.
>
> at each given fixed intervall:
> if (idle less than a watermark) {
> frequency full
> reinitialise count to 10
> } else if (idle more than another watermark) {
> decrement count
> if count is 0 {
> down one step the frequency
> }
> else reinitilize count to 10
>
>
> Note that in the latter case, the down step is performed only
> after 10 such comparison. In other word, intervall is ten times
> larger for the down side than the full frequency one.
>
> This work well when you can perform, say, 20 to 50 transitions per
> second. Otherwise, it is pretty bad.
>
Thanks very much!
But i'm not understanding if this high number of transitions are a
problem from the hardware point of view or from the software
implementation in freeBSD?
Best regards,
MC
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Bruno Ducrot wrote:
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
Marco Calviani wrote:
Hi,
2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>:
You have to load the cpufreq.ko module at boot.
Adding that line:
cpufreq_load = "YES"
to /boot/loader.conf
should be OK.
I have that line in that position, and it seems working. The point is
that i would like to change the driver and use (AFAIU) a better driver
for my system (est).
In particular i have:
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
Maybe i didn't understood well: but what i have to do to use the Intel
Enhanced SpeedStep driver?
You should send the full output of "sysctl dev.cpu". There is no
cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
at your dmesg to see if one is probing/attaching.
If you are using acpi and load cpufreq.ko, you've got all the cpufreq
drivers in one package. The right one for your platform will
automatically probe/attach.
powerd need some rework in order to get it working properly. There
is one FreeBSD project on that subject if you are interrested.
Well, thanks i'm very interested, although i'm not at all experienced
in kernel programming
I'm not inside this issue, but it would not be possible to "emulate"
the behaviour of the ondemand governor? (sorry if this question makes
no sense)
I have no idea what you mean by "on-demand governor". The only
automated control of cpu speed is either by the BIOS (which we can't
control) or the TM/TM2 (and that one is heat-based, not load-based).
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
Send me a URL to the datasheet that says Intel implemented this.
That algorithm is basically what powerd does. So just run powerd.
--
Nate
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 10:05:04AM -0800, Nate Lawson wrote:
> Marco Calviani wrote:
> >Hi,
> >
> >2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>:
> >
> >>You have to load the cpufreq.ko module at boot.
> >>Adding that line:
> >>cpufreq_load = "YES"
> >>to /boot/loader.conf
> >>should be OK.
> >
> >
> >I have that line in that position, and it seems working. The point is
> >that i would like to change the driver and use (AFAIU) a better driver
> >for my system (est).
> >In particular i have:
> >
> >dev.cpu.0.%desc: ACPI CPU
> >dev.cpu.0.%driver: cpu
> >dev.cpu.0.%location: handle=\_PR_.CPU0
> >dev.cpu.0.%pnpinfo: _HID=none _UID=0
> >dev.cpu.0.%parent: acpi0
> >
> >Maybe i didn't understood well: but what i have to do to use the Intel
> >Enhanced SpeedStep driver?
>
> You should send the full output of "sysctl dev.cpu". There is no
> cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look
> at your dmesg to see if one is probing/attaching.
>
> If you are using acpi and load cpufreq.ko, you've got all the cpufreq
> drivers in one package. The right one for your platform will
> automatically probe/attach.
>
> >>powerd need some rework in order to get it working properly. There
> >>is one FreeBSD project on that subject if you are interrested.
> >
> >Well, thanks i'm very interested, although i'm not at all experienced
> >in kernel programming
> >
> >I'm not inside this issue, but it would not be possible to "emulate"
> >the behaviour of the ondemand governor? (sorry if this question makes
> >no sense)
>
> I have no idea what you mean by "on-demand governor". The only
> automated control of cpu speed is either by the BIOS (which we can't
> control) or the TM/TM2 (and that one is heat-based, not load-based).
>
The ondemand governor is basically an implemation of the following
algorithm:
There is a counter, say count.
at each given fixed intervall:
if (idle less than a watermark) {
frequency full
reinitialise count to 10
} else if (idle more than another watermark) {
decrement count
if count is 0 {
down one step the frequency
}
else reinitilize count to 10
Note that in the latter case, the down step is performed only
after 10 such comparison. In other word, intervall is ten times
larger for the down side than the full frequency one.
This work well when you can perform, say, 20 to 50 transitions per
second. Otherwise, it is pretty bad.
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi Nate, 2005/11/30, Nate Lawson <[EMAIL PROTECTED]>: > > You should send the full output of "sysctl dev.cpu". There is no > cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look > at your dmesg to see if one is probing/attaching. > > sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1000 dev.cpu.0.freq_levels: 1800/24000 1600/2 1400/18000 1225/15750 1050/13500 1000/16000 875/14000 750/12000 625/1 600/12000 525/10500 450/9000 375/7500 300/6000 225/4500 150/3000 75/1500 and if useful, > dmesg | grep -i acpi Features=0xafe9f9bf acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 6 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 6 on acpi0 pci_link3: irq 6 on acpi0 pci_link4: irq 10 on acpi0 pci_link5: irq 0 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 10 on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 30.0 on pci0 pci2: on pcib2 acpi_lid0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 battery1: on acpi0 acpi_button0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio1 port 0x2f8-0x2ff irq 3 drq 1 on acpi0 > If you are using acpi and load cpufreq.ko, you've got all the cpufreq > drivers in one package. The right one for your platform will > automatically probe/attach. It seems that my system has recognized acpi_perf as the appropriate driver. But since my CPU is a dothan type centrino i would like to understand why is not possible to use the est driver. > I have no idea what you mean by "on-demand governor". The only > automated control of cpu speed is either by the BIOS (which we can't > control) or the TM/TM2 (and that one is heat-based, not load-based). > I was referring to this http://www.intel.com/cd/ids/developer/asmo-na/eng/195910.htm?prn=Y and http://lwn.net/Articles/55589/ introduced in linux kernel 2.6.9 . Just to remind: sorry if this is not applicable to the freeBSD kernel. In the linux case the system is much more responsive to actual user actions in respect to what i'm experiencing with powerd. If i can help in some way in testing i would like to contribute. > -- > Nate > Regards, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Marco Calviani wrote: Hi, 2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>: You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = "YES" to /boot/loader.conf should be OK. I have that line in that position, and it seems working. The point is that i would like to change the driver and use (AFAIU) a better driver for my system (est). In particular i have: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 Maybe i didn't understood well: but what i have to do to use the Intel Enhanced SpeedStep driver? You should send the full output of "sysctl dev.cpu". There is no cpufreq driver (est, acpi_perf, or other) driver running. Perhaps look at your dmesg to see if one is probing/attaching. If you are using acpi and load cpufreq.ko, you've got all the cpufreq drivers in one package. The right one for your platform will automatically probe/attach. powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. Well, thanks i'm very interested, although i'm not at all experienced in kernel programming I'm not inside this issue, but it would not be possible to "emulate" the behaviour of the ondemand governor? (sorry if this question makes no sense) I have no idea what you mean by "on-demand governor". The only automated control of cpu speed is either by the BIOS (which we can't control) or the TM/TM2 (and that one is heat-based, not load-based). -- Nate ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
Hi, 2005/11/30, Bruno Ducrot <[EMAIL PROTECTED]>: > You have to load the cpufreq.ko module at boot. > Adding that line: > cpufreq_load = "YES" > to /boot/loader.conf > should be OK. I have that line in that position, and it seems working. The point is that i would like to change the driver and use (AFAIU) a better driver for my system (est). In particular i have: dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 Maybe i didn't understood well: but what i have to do to use the Intel Enhanced SpeedStep driver? > powerd need some rework in order to get it working properly. There > is one FreeBSD project on that subject if you are interrested. Well, thanks i'm very interested, although i'm not at all experienced in kernel programming I'm not inside this issue, but it would not be possible to "emulate" the behaviour of the ondemand governor? (sorry if this question makes no sense) > Bruno Ducrot Thanks, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cpufreq and changing driver
On Wed, Nov 30, 2005 at 12:37:43PM +0100, Marco Calviani wrote: > Hi, > having seen on the cpufreq(4) man page that there is more than one > driver that is currently supported. In particular having a centrino > processor, i would like to use the est driver. Currently, by default, > the running driver is the one that comes with acpi (AFAIU), and i'm > using powerd to control the cpu frequency in adaptive mode. You have to load the cpufreq.ko module at boot. Adding that line: cpufreq_load = "YES" to /boot/loader.conf should be OK. > In particular doing comparison with the linux case in which i have > cpufreq with speedstep-centrino driver and the ondemand governor, in > this case the system is much more responsive and also the fans runs > much more quieter (although i cannot rely on proven data since i don't > know any benchmark program). In particular i understood that the > ondemand governor responds to the system much faster that powerd is > able to do. > > Is there someone who can share some impression or thoughts? powerd need some rework in order to get it working properly. There is one FreeBSD project on that subject if you are interrested. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
cpufreq and changing driver
Hi, having seen on the cpufreq(4) man page that there is more than one driver that is currently supported. In particular having a centrino processor, i would like to use the est driver. Currently, by default, the running driver is the one that comes with acpi (AFAIU), and i'm using powerd to control the cpu frequency in adaptive mode. In particular doing comparison with the linux case in which i have cpufreq with speedstep-centrino driver and the ondemand governor, in this case the system is much more responsive and also the fans runs much more quieter (although i cannot rely on proven data since i don't know any benchmark program). In particular i understood that the ondemand governor responds to the system much faster that powerd is able to do. Is there someone who can share some impression or thoughts? Best regards, MC ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
