01 Oct 2007 11:33:48 +0200, Andi Kleen <[email protected]>:
> Mikhail Kshevetskiy <[email protected]> writes:
> >
> > The same situation can be observed for linux-2.6.22.
>
> You're saying 2.6.22/x86-64 without any patches doesn't boot out of the box
> with C1E enabled? If yes what are the exact symptoms?
>
> -Andi
>
No, it boot and work normally. The only thing i bother, is the
additional 260 timer interrupts per seconds.
Here is short result:
c1e enabled:
-- power consumption about 23 watts
-- there is only C1 power state enabled
-- there are about 260 timer interrupts per seconds
tested with x86_64(2.6.22, 2.6.23-rc8, 2.6.23-rc8-hrt1 ),
i386(2.6.21, 2.6.22, 2.6.23-rc5-hrt1)
c1e disabled:
-- power consumption about 27 watts
-- there are no any power state enabled (including C1)
-- there are no additional 260 timer interrupts per seconds
tested with 2.6.23-rc6-hrt1/x86_64.
I want to reduce the power consumption of my notebook. I see the 2 possibility:
-- remove 260 additional timer interrupts (c1e enabled case )
-- force enable C1, C2 and C3 states (c1e disabled case)
Do you have any idea how it can be reached?
Mikhail Kshevetskiy
On Mon, 1 Oct 2007, Mikhail Kshevetskiy wrote:
> No, it boot and work normally. The only thing i bother, is the
> additional 260 timer interrupts per seconds.
> Here is short result:
>
> c1e enabled:
> -- power consumption about 23 watts
> -- there is only C1 power state enabled
> -- there are about 260 timer interrupts per seconds
> tested with x86_64(2.6.22, 2.6.23-rc8, 2.6.23-rc8-hrt1 ),
> i386(2.6.21, 2.6.22, 2.6.23-rc5-hrt1)
>
> c1e disabled:
> -- power consumption about 27 watts
> -- there are no any power state enabled (including C1)
> -- there are no additional 260 timer interrupts per seconds
> tested with 2.6.23-rc6-hrt1/x86_64.
>
> I want to reduce the power consumption of my notebook. I see the 2 possibility:
> -- remove 260 additional timer interrupts (c1e enabled case )
There is work in progress on a patch, which allows to utilize the hpet
timers as per cpu timers. This should solve the problem. Be patient.
Thanks,
tglx
> There is work in progress on a patch, which allows to utilize the hpet
> timers as per cpu timers. This should solve the problem. Be patient.
Given that e.g. ICH8 only has 3 HPET timers that seems doubtful
except for the special case of single-socket non hyper threaded dual core.
You'll probably do a lot of broadcasting and IPI'ing still.
Also you'll likely make user space unhappy which often requires
at least one free HPET timer for /dev/rtc. Ok I suppose that
could be replaced with a hrtimer.
-Andi
2007/10/1, Thomas Gleixner <[email protected]>:
> On Mon, 1 Oct 2007, Mikhail Kshevetskiy wrote:
> > No, it boot and work normally. The only thing i bother, is the
> > additional 260 timer interrupts per seconds.
> > Here is short result:
> >
> > c1e enabled:
> > -- power consumption about 23 watts
> > -- there is only C1 power state enabled
> > -- there are about 260 timer interrupts per seconds
> > tested with x86_64(2.6.22, 2.6.23-rc8, 2.6.23-rc8-hrt1 ),
> > i386(2.6.21, 2.6.22, 2.6.23-rc5-hrt1)
> >
> > c1e disabled:
> > -- power consumption about 27 watts
> > -- there are no any power state enabled (including C1)
> > -- there are no additional 260 timer interrupts per seconds
> > tested with 2.6.23-rc6-hrt1/x86_64.
> >
> > I want to reduce the power consumption of my notebook. I see the 2 possibility:
> > -- remove 260 additional timer interrupts (c1e enabled case )
>
> There is work in progress on a patch, which allows to utilize the hpet
> timers as per cpu timers. This should solve the problem. Be patient.
I can test it on i386/x86_64 architectures.
Mikhail Kshevetskiy
On Mon, 1 Oct 2007, Andi Kleen wrote:
> > There is work in progress on a patch, which allows to utilize the hpet
> > timers as per cpu timers. This should solve the problem. Be patient.
>
> Given that e.g. ICH8 only has 3 HPET timers that seems doubtful
> except for the special case of single-socket non hyper threaded dual core.
> You'll probably do a lot of broadcasting and IPI'ing still.
>
> Also you'll likely make user space unhappy which often requires
> at least one free HPET timer for /dev/rtc. Ok I suppose that
> could be replaced with a hrtimer.
Yes, we can replace rtc with a hrtimer. Also HPET can operate in non
legacy irq mode, so the legacy rtc is still available. So if the
number of hpet channels is greater/equal to the number of possible
CPUs it's perfectly fine and does not need IPI at all.
Thanks,
tglx
> So if the
> number of hpet channels is greater/equal to the number of possible
> CPUs it's perfectly fine and does not need IPI at all.
That is only a stop gap then. I don't see this being
generally true in the future. e.g. Intel announced SMT will be soon
back so even a standard dual core would exceed it with
current southbridges.
Also I'm not sure but I suspect non Intel HPETs have less than
three timers. Certainly they generally miss the 64bitness.
-Andi
On Mon, 1 Oct 2007, Andi Kleen wrote:
> > So if the
> > number of hpet channels is greater/equal to the number of possible
> > CPUs it's perfectly fine and does not need IPI at all.
>
> That is only a stop gap then. I don't see this being
> generally true in the future. e.g. Intel announced SMT will be soon
> back so even a standard dual core would exceed it with
> current southbridges.
Sigh. We have to deal with current hardware and the problems of exactly
that hardware. We have the possibility to solve problems and witchcrafting
what might happen next is not a good reason not to do so.
> Also I'm not sure but I suspect non Intel HPETs have less than
> three timers. Certainly they generally miss the 64bitness.
two timers are enough and 64 bit is nice to have, but not a requirement.
tglx
On 10/01/2007 11:21 AM, Andi Kleen wrote:
>
> Also I'm not sure but I suspect non Intel HPETs have less than
> three timers. Certainly they generally miss the 64bitness.
>
nVidia C51/MCP51 chipset, AMD Turion X2:
hpet0: 3 32-bit timers, 25000000 Hz