On Wed, 2005-08-31 at 22:42 +0530, Srivatsa Vaddagiri wrote:
> With this patch, time had kept up really well on one particular
> machine (Intel 4way Pentium 3 box) overnight, while
> on another newer machine (Intel 4way Xeon with HT) it didnt do so
> well (time sped up after 3 or 4 hours). Hence I consider this
> particular patch will need more review/work.
>
Are lost ticks really that common? If so, any idea what's disabling
interrupts for so long (or if it's a hardware issue)? And if not, it
seems like you'd need an artificial way to simulate lost ticks in order
to test this stuff.
Lee
Lee Revell wrote:
> On Wed, 2005-08-31 at 22:42 +0530, Srivatsa Vaddagiri wrote:
>
>>With this patch, time had kept up really well on one particular
>>machine (Intel 4way Pentium 3 box) overnight, while
>>on another newer machine (Intel 4way Xeon with HT) it didnt do so
>>well (time sped up after 3 or 4 hours). Hence I consider this
>>particular patch will need more review/work.
>>
>
>
> Are lost ticks really that common? If so, any idea what's disabling
> interrupts for so long (or if it's a hardware issue)? And if not, it
> seems like you'd need an artificial way to simulate lost ticks in order
> to test this stuff.
In my experience, turning off DMA for IDE disks is a pretty good way to
generate lost ticks :-)
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
On Sat, 2005-09-03 at 14:18 +1000, Peter Williams wrote:
> In my experience, turning off DMA for IDE disks is a pretty good way to
> generate lost ticks :-)
For this to "work" you have to unset "unmask IRQ" with hdparm, right?
Lee
Lee Revell wrote:
> On Sat, 2005-09-03 at 14:18 +1000, Peter Williams wrote:
>
>>In my experience, turning off DMA for IDE disks is a pretty good way to
>>generate lost ticks :-)
>
>
> For this to "work" you have to unset "unmask IRQ" with hdparm, right?
I'm not familiar with that method. When I've experienced this it's been
due to me accidentally not configuring IDE DMA during configuration.
Peter
--
Peter Williams [email protected]
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
Lee Revell wrote:
> Are lost ticks really that common? If so, any idea what's disabling
>
>interrupts for so long (or if it's a hardware issue)? And if not, it
>seems like you'd need an artificial way to simulate lost ticks in order
>to test this stuff.
>
>Lee
>
>
Yes - I know many people with laptops who have this lost ticks problem.
So no simulation and/or
special efforts required. If anyone wants a test bed - my laptop is the
perfect instrument.
In my case the rip is always as acpi_processor_idle now a days. Earlier
it used to be at acpi_ec_read.
Parag
On Sat, Sep 03, 2005 at 12:05:00AM -0400, Lee Revell wrote:
> Are lost ticks really that common? If so, any idea what's disabling
It becomes common with a patch like dynamic ticks, where we purposefully
skip ticks when CPU is idle. When the CPU wakes up, we have to regain
the lost/skipped ticks and thats where I ran into incorrect lost-tick
calculation issues.
> interrupts for so long (or if it's a hardware issue)? And if not, it
> seems like you'd need an artificial way to simulate lost ticks in order
> to test this stuff.
Dyn-tick patch is enought to simulate these lost ticks!
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
On Sat, 2005-09-03 at 01:15 -0400, Parag Warudkar wrote:
> Lee Revell wrote:
>
> > Are lost ticks really that common? If so, any idea what's disabling
> >
> >interrupts for so long (or if it's a hardware issue)? And if not, it
> >seems like you'd need an artificial way to simulate lost ticks in order
> >to test this stuff.
> >
> >Lee
> >
> >
> Yes - I know many people with laptops who have this lost ticks problem.
> So no simulation and/or
> special efforts required. If anyone wants a test bed - my laptop is the
> perfect instrument.
>
> In my case the rip is always as acpi_processor_idle now a days. Earlier
> it used to be at acpi_ec_read.
Ah, OK, I forgot about SMM traps.
Lee
Hi!
> > With this patch, time had kept up really well on one particular
> > machine (Intel 4way Pentium 3 box) overnight, while
> > on another newer machine (Intel 4way Xeon with HT) it didnt do so
> > well (time sped up after 3 or 4 hours). Hence I consider this
> > particular patch will need more review/work.
> >
>
> Are lost ticks really that common? If so, any idea what's disabling
> interrupts for so long (or if it's a hardware issue)? And if not, it
> seems like you'd need an artificial way to simulate lost ticks in order
> to test this stuff.
Try running this from userspace (and watch for time going completely
crazy). Try it in mainline, too; it broke even vanilla some time
ago. Need to run as root.
Pavel
void
main(void)
{
int i;
iopl(3);
while (1) {
asm volatile("cli");
// for (i=0; i<20000000; i++)
for (i=0; i<1000000000; i++)
asm volatile("");
asm volatile("sti");
sleep(1);
}
}
--
if you have sharp zaurus hardware you don't need... you know my address
On Tue, Sep 06, 2005 at 12:32:32PM +0200, Pavel Machek wrote:
> Try running this from userspace (and watch for time going completely
> crazy). Try it in mainline, too; it broke even vanilla some time
> ago. Need to run as root.
Note that kernel relies on some backing time source (like TSC/PM)
to recover lost ticks (& time). And these backing time source have
their own limitation on how many max lost ticks you can recover,
which in turn means how long you can have interrupts blocked.
In case of TSC, since only 32-bit previous snapshot is maintained (in x86
atleast) it allows for ticks to be lost only upto a second (if I remember
correctly), while the 24-bit ACPI PM timer allows for upto 3-4
seconds.
I found that the while loop below takes 3.66 seconds running
on a 1.8GHz P4 CPU. That may be too much if kernel is using
(32-bit snapshot of) TSC to recover ticks, while maybe just
at the max limit allowed for ACPI PM timer.
I will test this code with the lost-tick recovery fixes
for ACPI PM timer that I sent out and let you know
how it performs!
> for (i=0; i<1000000000; i++)
> asm volatile("");
--
Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017
On Sat, 2005-09-03 at 00:05 -0400, Lee Revell wrote:
> On Wed, 2005-08-31 at 22:42 +0530, Srivatsa Vaddagiri wrote:
> > With this patch, time had kept up really well on one particular
> > machine (Intel 4way Pentium 3 box) overnight, while
> > on another newer machine (Intel 4way Xeon with HT) it didnt do so
> > well (time sped up after 3 or 4 hours). Hence I consider this
> > particular patch will need more review/work.
> >
>
> Are lost ticks really that common? If so, any idea what's disabling
> interrupts for so long (or if it's a hardware issue)? And if not, it
> seems like you'd need an artificial way to simulate lost ticks in order
> to test this stuff.
Pavel came up with a pretty good test for this awhile back.
http://marc.theaimsgroup.com/?l=linux-kernel&m=110519095425851&w=2
Adding:
unsigned long mask = 0x1;
sched_setaffinity(0, sizeof(mask), &mask);
to the top helps it work on SMP systems.
thanks
-john