Hi,
I have a few questions about the PM Dual Core and how could it really work
with Linux. Sorry if there are new patches on LKML about any of these things:
Could each processor or die, have it's own cpufreq scaling governor?
Is there a way to allow one die to be idle and let the other one normal?
So in other words, could we manage these processors speedstep, utilization and
workload individually?
Thanks!
.Alejandro
Alejandro Bonilla wrote:
> Hi,
>
> I have a few questions about the PM Dual Core and how could it really work
> with Linux. Sorry if there are new patches on LKML about any of these things:
>
> Could each processor or die, have it's own cpufreq scaling governor?
Sure. On a laptop, if you don't need dual core power, it makes sense to
turn off the unused core, even.
Jeff
On Sat, 18 Mar 2006 03:58:22 -0500, Jeff Garzik wrote
> Alejandro Bonilla wrote:
> > Hi,
> >
> > I have a few questions about the PM Dual Core and how could it really work
> > with Linux. Sorry if there are new patches on LKML about any of these things:
> >
> > Could each processor or die, have it's own cpufreq scaling governor?
>
> Sure. On a laptop, if you don't need dual core power, it makes
> sense to turn off the unused core, even.
>
> Jeff
Jeff,
For some reason, while I was writing this email, I knew you would be the first
to reply. LOL. Anyway. Does this need new patches sent to LKML or nice
commands to make this work or any idea if stock cpufreqd should manage the
cores separatelly? I haven't got that to work on 2.6.15 so far. How flexible
can we get with the cores?
Thanks for your time,
.Alejandro
On Sat, 2006-03-18 at 02:35 -0600, Alejandro Bonilla wrote:
> Hi,
>
> I have a few questions about the PM Dual Core and how could it really work
> with Linux. Sorry if there are new patches on LKML about any of these things:
>
> Could each processor or die, have it's own cpufreq scaling governor?
>
> Is there a way to allow one die to be idle and let the other one normal?
>
> So in other words, could we manage these processors speedstep, utilization and
> workload individually?
afaik the cpuspeed daemon already supports this.
(not all dual core hardware can do this, but for the hw that can,
cpuspeed supports it)
On Sat, Mar 18, 2006 at 03:03:40AM -0600, Alejandro Bonilla wrote:
> On Sat, 18 Mar 2006 03:58:22 -0500, Jeff Garzik wrote
> > Alejandro Bonilla wrote:
> > > Hi,
> > >
> > > I have a few questions about the PM Dual Core and how could it really work
> > > with Linux. Sorry if there are new patches on LKML about any of these things:
> > >
> > > Could each processor or die, have it's own cpufreq scaling governor?
> >
> > Sure. On a laptop, if you don't need dual core power, it makes
> > sense to turn off the unused core, even.
> >
> > Jeff
>
> Jeff,
>
> For some reason, while I was writing this email, I knew you would be the first
> to reply. LOL. Anyway. Does this need new patches sent to LKML or nice
> commands to make this work or any idea if stock cpufreqd should manage the
> cores separatelly? I haven't got that to work on 2.6.15 so far. How flexible
no, currently cpufreqd applies the governor and limits to all available
cpus. Is it really possible to run the 2 cores at different speeds?
I definitely need to upgrade my hardware and get one of those dual core
babies to play with.
Oh, and BTW patches to cpufreqd are welcome in the meantime :)
ciao
--
mattia
:wq!
Alejandro Bonilla wrote:
> Hi,
>
> I have a few questions about the PM Dual Core and how could it really work
> with Linux. Sorry if there are new patches on LKML about any of these things:
>
> Could each processor or die, have it's own cpufreq scaling governor?
>
> Is there a way to allow one die to be idle and let the other one normal?
>
> So in other words, could we manage these processors speedstep, utilization and
> workload individually?
This depends on your hardware. I was reading the Sossaman data sheet the
other day, and it says that the entire chip must run at the same
frequency. You can set each core to a different frequency, but the
hardware chooses the higher of the two. Likewise, the entire chip can
sleep, but individual cores can only go into C1. I imagine the Core Duo
is the same.
IIRC, the dual-core Opterons behave a little differently but the two
cores still have to run at the same frequency.
Wes Felter - [email protected]
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of Mattia Dongili
>Sent: Saturday, March 18, 2006 2:49 AM
>To: Alejandro Bonilla
>Cc: Jeff Garzik; [email protected]
>Subject: Re: Dual Core on Linux questions
>
>On Sat, Mar 18, 2006 at 03:03:40AM -0600, Alejandro Bonilla wrote:
>> On Sat, 18 Mar 2006 03:58:22 -0500, Jeff Garzik wrote
>> > Alejandro Bonilla wrote:
>> > > Hi,
>> > >
>> > > I have a few questions about the PM Dual Core and how
>could it really work
>> > > with Linux. Sorry if there are new patches on LKML about
>any of these things:
>> > >
>> > > Could each processor or die, have it's own cpufreq
>scaling governor?
>> >
>> > Sure. On a laptop, if you don't need dual core power, it makes
>> > sense to turn off the unused core, even.
>> >
>> > Jeff
>>
>> Jeff,
>>
>> For some reason, while I was writing this email, I knew you
>would be the first
>> to reply. LOL. Anyway. Does this need new patches sent to
>LKML or nice
>> commands to make this work or any idea if stock cpufreqd
>should manage the
>> cores separatelly? I haven't got that to work on 2.6.15 so
>far. How flexible
>
>no, currently cpufreqd applies the governor and limits to all available
>cpus. Is it really possible to run the 2 cores at different speeds?
>I definitely need to upgrade my hardware and get one of those dual core
>babies to play with.
>Oh, and BTW patches to cpufreqd are welcome in the meantime :)
>
>From cpufreq perspective multiple things are possible in the way
processor will support the multi-core frequency changing. and most of
the things are handled at cpufreq inside kernel. I think there should be
minima changes required in cpufreqd if any.
Options:
1) Multiple core can manage frequency independently: In this case,
cpufreq exports separate interfaces for each cpu in
/sys/devices/system/cpu/cpuX. So, cpufreqd should work as it would work
on an SMP system (Assuming that cpufreqd works fine on an SMP system
today ;-))
2) Multiple cores can be at a single frequency, but hardware will
coordinate between two cores internally (pick the highest frequency
request from two cores and run both of them at that frequency). This
will be very much similar to 1, in the way in which cpufreq and kernel
handles it.
3) Multiple cores can be at a single frequency and hardware depends on
OS to do the coordination, pick the maximum of all the requests from the
cores and set the frequency using appropriate hardware interface. This
is the case, where cpufreqd may need a change. In this case, say CPU 0
and 1 are two different cores on same package and they share frequency
and OS has to coordinate the freq request from these two CPUs. In this
case, /sys/devices/system/cpu/cpu1/cpufreq will be kind of a symbolic
link to /sys/devices/system/cpu/cpu0/cpufreq. Cpufreq tells that these
two are dependent by using "affected_cpus" in the same sysfs directory
(in this case "0 1"). Now, if cpufreqd does a set_speed on cpu0 and
cpu1, both CPUs will be affected. Cpufreqd should be aware that these
CPUs are dependent and change freq based on maximum utilization of these
two CPUs.
Thanks,
Venki
Pallipadi, Venkatesh wrote:
>>From cpufreq perspective multiple things are possible in the way
> processor will support the multi-core frequency changing. and most of
> the things are handled at cpufreq inside kernel. I think there should be
> minima changes required in cpufreqd if any.
> Options:
4) we power down a core.
>-----Original Message-----
>From: Jeff Garzik [mailto:[email protected]]
>Sent: Wednesday, March 22, 2006 7:45 PM
>To: Pallipadi, Venkatesh
>Cc: Mattia Dongili; Alejandro Bonilla; [email protected]
>Subject: Re: Dual Core on Linux questions
>
>Pallipadi, Venkatesh wrote:
>>>From cpufreq perspective multiple things are possible in the way
>> processor will support the multi-core frequency changing. and most of
>> the things are handled at cpufreq inside kernel. I think
>there should be
>> minima changes required in cpufreqd if any.
>> Options:
>
>
>4) we power down a core.
>
That is more of a logical hotplug issue than cpufreq. But, it is better
to keep the CPU on and scheduler do the best use of it. If CPU has
nothing to run, it will go to deepest C-state possible and idle in that
state anyway.
Thanks,
Venki
Hi,
On Wed, Mar 22, 2006 at 07:36:42PM -0800, Pallipadi, Venkatesh wrote:
[...]
> minima changes required in cpufreqd if any.
> Options:
> 1) Multiple core can manage frequency independently: In this case,
> cpufreq exports separate interfaces for each cpu in
> /sys/devices/system/cpu/cpuX. So, cpufreqd should work as it would work
> on an SMP system (Assuming that cpufreqd works fine on an SMP system
> today ;-))
hehe, this is exactely where cpufreqd needs some work as it doesn't
distinguish between UP and MP currently, it just applies the same
cpufreq policy to all available processors.
But I'm already working on this.
> 2) Multiple cores can be at a single frequency, but hardware will
> coordinate between two cores internally (pick the highest frequency
> request from two cores and run both of them at that frequency). This
> will be very much similar to 1, in the way in which cpufreq and kernel
> handles it.
cpufreqd has no problems here.
> 3) Multiple cores can be at a single frequency and hardware depends on
> OS to do the coordination, pick the maximum of all the requests from the
> cores and set the frequency using appropriate hardware interface. This
> is the case, where cpufreqd may need a change. In this case, say CPU 0
> and 1 are two different cores on same package and they share frequency
> and OS has to coordinate the freq request from these two CPUs. In this
> case, /sys/devices/system/cpu/cpu1/cpufreq will be kind of a symbolic
> link to /sys/devices/system/cpu/cpu0/cpufreq. Cpufreq tells that these
> two are dependent by using "affected_cpus" in the same sysfs directory
yes, cpufreqd needs some work on this, but it will be easily handled
once 1) is done and anyway it is't that bad here currenlty, it will
just write to both .../cpu0 and .../cpu1 the same profile.
> (in this case "0 1"). Now, if cpufreqd does a set_speed on cpu0 and
> cpu1, both CPUs will be affected. Cpufreqd should be aware that these
> CPUs are dependent and change freq based on maximum utilization of these
> two CPUs.
Oh, there's the ondemand governor for this.
A little digression though just to point out that cpufreqd works
differently from cpuspeed, speedfreq et al.
It collects system status data (acpi/apm/pmu data, cpu load,
sensors data,...) and applies a cpufreq policy based on user defined
rules (eg: when battery is between 5% and 50% and ac is unplugged run
with ondemand @ 40%-70% - quite like the old speestep applet I found on
win2k on this laptop some years ago).
No best frequency caclulation is done, too many parameters and for just
the cpu load we have the excellent ondemand governor.
Thanks for the useful insight!
--
mattia
:wq!
Jeff Garzik wrote:
> Pallipadi, Venkatesh wrote:
>>> From cpufreq perspective multiple things are possible in the way
>> processor will support the multi-core frequency changing. and most of
>> the things are handled at cpufreq inside kernel. I think there should be
>> minima changes required in cpufreqd if any.
>> Options:
>
>
> 4) we power down a core.
>
Is this just for completeness of the set, something someone might do
someday, or does someone really have a hotplug core product?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Bill Davidsen wrote:
> Jeff Garzik wrote:
>> Pallipadi, Venkatesh wrote:
>>>> From cpufreq perspective multiple things are possible in the way
>>> processor will support the multi-core frequency changing. and most of
>>> the things are handled at cpufreq inside kernel. I think there should be
>>> minima changes required in cpufreqd if any.
>>> Options:
>>
>>
>> 4) we power down a core.
>>
> Is this just for completeness of the set, something someone might do
> someday, or does someone really have a hotplug core product?
Not hotplug, just power it down.
Jeff