[patch] voluntary-preempt-2.6.8-rc2-O2

[patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

here's the latest version of the voluntary-preempt patch:
  
  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2

this patch is mainly a stabilization effort. I dropped the irq-threads
code added in -M5 and rewrote it from scratch based on -L2 - it is
simpler and should be more robust.

The same /proc/irq/* configuration switches are still present, but i
added the following additional rule: if _any_ handler of a given IRQ is
marked as non-threaded then all handlers will be executed non-threaded
as well.

E.g. if you have the following handlers on IRQ 10:

 10:      11584   IO-APIC-level  eth0, eth1, eth2

and you change /proc/irq/16/eth1/threaded from 1 to 0 then the eth0 and
eth2 handlers will be executed non-threaded as well. (This rule only
enforces what the hardware enforces anyway, none of the previous patches
allowed true separation of these handlers.)

i also changed the IO-APIC level-triggered code to be robust when
redirection is done. The noapic workaround should not be necessary
anymore.

the keyboard lockups are now hopefully all gone too - i've tested
IO-APIC and non-IO-APIC setups as well and NumLock/ScrollLock works fine
in all sorts of workloads.

Let me know if you still have any problems.

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Felipe Alfaro Solana]

On Sun, 2004-08-01 at 21:30 +0200, Ingo Molnar wrote:
> here's the latest version of the voluntary-preempt patch:
>   
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2
> 
> this patch is mainly a stabilization effort. I dropped the irq-threads
> code added in -M5 and rewrote it from scratch based on -L2 - it is
> simpler and should be more robust.
> 
> The same /proc/irq/* configuration switches are still present, but i
> added the following additional rule: if _any_ handler of a given IRQ is
> marked as non-threaded then all handlers will be executed non-threaded
> as well.
> 
> E.g. if you have the following handlers on IRQ 10:
> 
>  10:      11584   IO-APIC-level  eth0, eth1, eth2
> 
> and you change /proc/irq/16/eth1/threaded from 1 to 0 then the eth0 and
> eth2 handlers will be executed non-threaded as well. (This rule only
> enforces what the hardware enforces anyway, none of the previous patches
> allowed true separation of these handlers.)
> 
> i also changed the IO-APIC level-triggered code to be robust when
> redirection is done. The noapic workaround should not be necessary
> anymore.
> 
> the keyboard lockups are now hopefully all gone too - i've tested
> IO-APIC and non-IO-APIC setups as well and NumLock/ScrollLock works fine
> in all sorts of workloads.
> 
> Let me know if you still have any problems.

I'll be away on vacations for about two weeks, but before leaving, I
wanted to test run 2.6.8-rc2-bk11 plus voluntary-preempt-O2 on my P4 box
with both ACPI and IO/APIC enabled, voluntary-preempt=3 and preempt=1
and it seems to be working fine (I still haven't seen any hard locks).

# cat /proc/interrupts
           CPU0
  0:     114044    IO-APIC-edge  timer
  1:        497    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:       9289    IO-APIC-edge  ide0
 15:         54    IO-APIC-edge  ide1
 17:       1299   IO-APIC-level  Intel 82801BA-ICH2
 19:      13408   IO-APIC-level  uhci_hcd
 20:        279   IO-APIC-level  eth0
 23:          0   IO-APIC-level  uhci_hcd
NMI:          0
LOC:     113967
ERR:          0
MIS:          0

# grep . /proc/irq/*/*/threaded
/proc/irq/14/ide0/threaded:1
/proc/irq/15/ide1/threaded:1
/proc/irq/17/Intel 82801BA-ICH2/threaded:1
/proc/irq/19/uhci_hcd/threaded:1
/proc/irq/1/i8042/threaded:1
/proc/irq/20/eth0/threaded:1
/proc/irq/23/uhci_hcd/threaded:1
/proc/irq/8/rtc/threaded:1
/proc/irq/9/acpi/threaded:1

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Daniel Schmitt]

On Sunday 01 August 2004 21:30, Ingo Molnar wrote:
> here's the latest version of the voluntary-preempt patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2

One minor problem: this crashes hard (in interrupt context, stack pointer is 
bogus) during early boot iff CONFIG_REGPARM is set. With the earlier patches, 
this didn't happen. No ill effects so far with the default ABI; performance 
(apart from the usual reiserfs problems) is flawless.

Context: plain 2.6.8-rc2 + O2, gcc (GCC) 3.3.4 20040623 (Gentoo Linux 
3.3.4-r1, ssp-3.3.2-2, pie-8.7.6), EPoX 8RDA3+ (nForce2) motherboard. If you 
need more information, let me know.

Ciao,

Daniel.

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Matt Heler]

Ingo,

I get the following error below on with your patch applied on stock 
2.6.8-rc2 ...

  CC      kernel/softirq.o
  CC      kernel/hardirq.o
kernel/hardirq.c:51: error: conflicting types for 'generic_handle_IRQ_event'
include/linux/irq.h:78: error: previous declaration of 
'generic_handle_IRQ_event' was here
kernel/hardirq.c:51: error: conflicting types for 'generic_handle_IRQ_event'
include/linux/irq.h:78: error: previous declaration of 
'generic_handle_IRQ_event' was here
make[1]: *** [kernel/hardirq.o] Error 1
make: *** [kernel] Error 2


Matt H.


On Sunday 01 August 2004 12:30 pm, Ingo Molnar wrote:
> here's the latest version of the voluntary-preempt patch:
>
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2
>
> this patch is mainly a stabilization effort. I dropped the irq-threads
> code added in -M5 and rewrote it from scratch based on -L2 - it is
> simpler and should be more robust.
>
> The same /proc/irq/* configuration switches are still present, but i
> added the following additional rule: if _any_ handler of a given IRQ is
> marked as non-threaded then all handlers will be executed non-threaded
> as well.
>
> E.g. if you have the following handlers on IRQ 10:
>
>  10:      11584   IO-APIC-level  eth0, eth1, eth2
>
> and you change /proc/irq/16/eth1/threaded from 1 to 0 then the eth0 and
> eth2 handlers will be executed non-threaded as well. (This rule only
> enforces what the hardware enforces anyway, none of the previous patches
> allowed true separation of these handlers.)
>
> i also changed the IO-APIC level-triggered code to be robust when
> redirection is done. The noapic workaround should not be necessary
> anymore.
>
> the keyboard lockups are now hopefully all gone too - i've tested
> IO-APIC and non-IO-APIC setups as well and NumLock/ScrollLock works fine
> in all sorts of workloads.
>
> Let me know if you still have any problems.
>
> 	Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Lee Revell]

On Sun, 2004-08-01 at 15:30, Ingo Molnar wrote:
> here's the latest version of the voluntary-preempt patch:
>   
>   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2

This works as well as L2, possibly better, because the 42 usec result
was with the rtc irq threaded, it is now direct.  I will post numbers
soon.

Lee

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Lee Revell]

On Sun, 2004-08-01 at 21:45, Lee Revell wrote:
> I will post numbers soon.

I will be out of town for a few days, so this is the last batch.  On my
hardware at least, all the latency problems have been resolved.

Delay   Count
-----   -----
6       2880
7       173347
8       311550
9       51870
10      16382
11      12687
12      11757
13      16355
14      14338
15      10980
16      8152
17      6837
18      5331
19      6593
20      5175
21      4181
22      2189
23      1280
24      622
25      461
26      327
27      230
28      195
29      183
30      277
31      271
32      263
33      224
34      143
35      78
36      62
37      78
38      66
39      60
40      55
41      39
42      25
43      14
44      7
45      6
46      5
47      4
48      1
49      5
50      6
51      3
52      1
54      1
55      2
56      2

Lee

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Felipe Alfaro Solana]

On Mon, 2004-08-02 at 01:20 +0200, Daniel Schmitt wrote:
> On Sunday 01 August 2004 21:30, Ingo Molnar wrote:
> > here's the latest version of the voluntary-preempt patch:
> >
> >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2
> 
> One minor problem: this crashes hard (in interrupt context, stack pointer is 
> bogus) during early boot iff CONFIG_REGPARM is set. With the earlier patches, 
> this didn't happen. No ill effects so far with the default ABI; performance 
> (apart from the usual reiserfs problems) is flawless.

Hmmm... I have CONFIG_REGPARM enabled and it didn't crash for me at all.

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Felipe Alfaro Solana]

On Sun, 2004-08-01 at 16:44 -0700, Matt Heler wrote:
> Ingo,
> 
> I get the following error below on with your patch applied on stock 
> 2.6.8-rc2 ...
> 
>   CC      kernel/softirq.o
>   CC      kernel/hardirq.o
> kernel/hardirq.c:51: error: conflicting types for 'generic_handle_IRQ_event'
> include/linux/irq.h:78: error: previous declaration of 
> 'generic_handle_IRQ_event' was here
> kernel/hardirq.c:51: error: conflicting types for 'generic_handle_IRQ_event'
> include/linux/irq.h:78: error: previous declaration of 
> 'generic_handle_IRQ_event' was here
> make[1]: *** [kernel/hardirq.o] Error 1
> make: *** [kernel] Error 2

Try removing the "asmlinkage" from the definition of
"generic_handle_IRQ_event" in file "kernel/hardirq.c".

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

* Felipe Alfaro Solana <felipe_alfaro@linuxmail.org> wrote:

> > kernel/hardirq.c:51: error: conflicting types for 'generic_handle_IRQ_event'
> > include/linux/irq.h:78: error: previous declaration of 
> > 'generic_handle_IRQ_event' was here

> Try removing the "asmlinkage" from the definition of
> "generic_handle_IRQ_event" in file "kernel/hardirq.c".

i solved it by adding asmlinkage to irq.h - i've updated the -O2 patch
to include this fix. It needs to stay asmlinkage because e.g. the 4K
stacks code calls it from within an assembly section which assumes the
function follows the normal calling convention (and not e.g. regparm).

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

* Lee Revell <rlrevell@joe-job.com> wrote:

> On Sun, 2004-08-01 at 21:45, Lee Revell wrote:
> > I will post numbers soon.
> 
> I will be out of town for a few days, so this is the last batch.  On my
> hardware at least, all the latency problems have been resolved.

> 55      2
> 56      2

nice. I'd not worry about the identity of the -M5 latencies too much if
they are gone in -O2.

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Lenar Lõhmus]

Ingo Molnar wrote:

>here's the latest version of the voluntary-preempt patch:
>  
>  http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-O2
>  
>
Rediff against 2.6.8-rc2-mm2 would be nice if possible (there are some 
rejects right now).

Lenar

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Shane Shrybman]

I was unable to boot -O2. It seemed to hang up when it got to the
aic7xxx(29160) scsi controller.

Boot messages copied by hand:

IRQ #16 thread started up.
delay 5 -10 secs
IRQ #19 thread started up.
delay 5 -10 secs
ahc_intr: HOST_MSG_LOOP bad phase 0x0
(repeats every 10-20 secs)
Waited a few minutes here before giving up and hitting reset.

Here is /proc/interrupts in 2.6.7-mm7
           CPU0       
  0:     740456    IO-APIC-edge  timer
  1:       1417    IO-APIC-edge  i8042
  8:          4    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:         14    IO-APIC-edge  ide0
 15:         14    IO-APIC-edge  ide1
 16:        178   IO-APIC-level  ide3, EMU10K1
 17:       2491   IO-APIC-level  eth0
 19:      10335   IO-APIC-level  aic7xxx, bttv0, Bt87x audio
 21:      29074   IO-APIC-level  uhci_hcd, uhci_hcd, uhci_hcd, uhci_hcd
 22:          0   IO-APIC-level  VIA8233
NMI:          0 
LOC:     740415 
ERR:          0
MIS:          0

Also, had to turn of parport in the config to get it to compile.

drivers/parport/share.c:77: unknown field `generic_enable_irq' specified
in initializer
drivers/parport/share.c:78: unknown field `generic_disable_irq'
specified in initializer

Regards,

Shane

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

On Mon, 2 Aug 2004, Shane Shrybman wrote:

> I was unable to boot -O2. It seemed to hang up when it got to the
> aic7xxx(29160) scsi controller.

does it boot with voluntary-preempt=2 on the boot command line? (or with 
voluntary-preempt=1)?

if it boots this way you can turn it back on runtime by changing
/proc/sys/kernel/voluntary_preemption back to 3 and turning on IRQ
threading for each interrupt via /proc/irq/*/threaded.

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Shane Shrybman]

On Tue, 2004-08-03 at 05:19, Ingo Molnar wrote:
> On Mon, 2 Aug 2004, Shane Shrybman wrote:
> 
> > I was unable to boot -O2. It seemed to hang up when it got to the
> > aic7xxx(29160) scsi controller.
> 
> does it boot with voluntary-preempt=2 on the boot command line? (or with 
> voluntary-preempt=1)?
> 

Nope, didn't boot with either voluntary-preempt=1 or 2 on the boot
command line. Booting stopped at the scsi controller again.

It did boot with just acpi=off.

> if it boots this way you can turn it back on runtime by changing
> /proc/sys/kernel/voluntary_preemption back to 3 and turning on IRQ
> threading for each interrupt via /proc/irq/*/threaded.
> 
> 	Ingo
> 

Regards,

Shane

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

On Tue, 3 Aug 2004, Shane Shrybman wrote:

> > > I was unable to boot -O2. It seemed to hang up when it got to the
> > > aic7xxx(29160) scsi controller.
> > 
> > does it boot with voluntary-preempt=2 on the boot command line? (or with 
> > voluntary-preempt=1)?
> > 
> 
> Nope, didn't boot with either voluntary-preempt=1 or 2 on the boot
> command line. Booting stopped at the scsi controller again.
> 
> It did boot with just acpi=off.

does the non-patched kernel boot?

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

On Mon, 2 Aug 2004, Shane Shrybman wrote:

> Also, had to turn of parport in the config to get it to compile.
> 
> drivers/parport/share.c:77: unknown field `generic_enable_irq' specified
> in initializer
> drivers/parport/share.c:78: unknown field `generic_disable_irq'
> specified in initializer

thx - i fixed this in -O3.

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Shane Shrybman]

On Tue, 2004-08-03 at 10:09, Ingo Molnar wrote:
> On Tue, 3 Aug 2004, Shane Shrybman wrote:
> 
> > > > I was unable to boot -O2. It seemed to hang up when it got to the
> > > > aic7xxx(29160) scsi controller.
> > > 
> > > does it boot with voluntary-preempt=2 on the boot command line? (or with 
> > > voluntary-preempt=1)?
> > > 
> > 
> > Nope, didn't boot with either voluntary-preempt=1 or 2 on the boot
> > command line. Booting stopped at the scsi controller again.
> > 
> > It did boot with just acpi=off.
> 
> does the non-patched kernel boot?
> 

I am in vanilla 2.6.8-rc2 now and it seems to be fine.

> 	Ingo
> 

Regards,

Shane

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

On Tue, 3 Aug 2004, Shane Shrybman wrote:

> > > Nope, didn't boot with either voluntary-preempt=1 or 2 on the boot
> > > command line. Booting stopped at the scsi controller again.
> > > 
> > > It did boot with just acpi=off.
> > 
> > does the non-patched kernel boot?
> > 
> 
> I am in vanilla 2.6.8-rc2 now and it seems to be fine.

does it boot fine with the patch applied but the APIC turned off in the 
.config?

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Shane Shrybman]

On Tue, 2004-08-03 at 12:29, Ingo Molnar wrote:
> On Tue, 3 Aug 2004, Shane Shrybman wrote:
> 
> > > > Nope, didn't boot with either voluntary-preempt=1 or 2 on the boot
> > > > command line. Booting stopped at the scsi controller again.
> > > > 
> > > > It did boot with just acpi=off.
> > > 
> > > does the non-patched kernel boot?
> > > 
> > 
> > I am in vanilla 2.6.8-rc2 now and it seems to be fine.
> 
> does it boot fine with the patch applied but the APIC turned off in the 
> .config?
> 

Yes it does.

> 	Ingo
> 

Shane

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Rudo Thomas]

> thx - i fixed this in -O3.

Hi, Ingo.

I just wanted to report that O3 (+preempt-timing-O2) locks up hard at random
occasions, even with voluntary-preempt=2 preempt=1 set at boot time.
I never changed any of /proc/irq/*/threaded.

I will provide any information needed to hunt this down.

Rudo.

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Ingo Molnar]

On Wed, 4 Aug 2004, Rudo Thomas wrote:

> > thx - i fixed this in -O3.
> 
> Hi, Ingo.
> 
> I just wanted to report that O3 (+preempt-timing-O2) locks up hard at
> random occasions, even with voluntary-preempt=2 preempt=1 set at boot
> time. I never changed any of /proc/irq/*/threaded.
> 
> I will provide any information needed to hunt this down.

could you check whether it works with all APIC options turned off in the
.config?

	Ingo

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Peter Zijlstra]

Rudo Thomas wrote:

>>thx - i fixed this in -O3.
>>    
>>
>
>Hi, Ingo.
>
>I just wanted to report that O3 (+preempt-timing-O2) locks up hard at random
>occasions, even with voluntary-preempt=2 preempt=1 set at boot time.
>I never changed any of /proc/irq/*/threaded.
>
>I will provide any information needed to hunt this down.
>
>Rudo.
>  
>
Hi Igno,

I have the same troubles with O3 at home on my SMP machine, however
since the same kernel (2.6.8-rc2-mm2-O3) works flawlessly here at work
on a UP P4 I thought it to be SMP related.

I also tried booting my dual athlon with noapic but that did not solve
the problem.

I have not had enough time yet to file a proper bug report but seeing
this message I wanted to second it.

Are there any known SMP related problems with your patches?

and would my dmesg and .config from home be enough ?

kind regards,

Peter Zijlstra

Re: [patch] voluntary-preempt-2.6.8-rc2-mm2-O3

[Peter Zijlstra]

Rudo Thomas wrote:

>>thx - i fixed this in -O3.
>>    
>>
>
>Hi, Ingo.
>
>I just wanted to report that O3 (+preempt-timing-O2) locks up hard at random
>occasions, even with voluntary-preempt=2 preempt=1 set at boot time.
>I never changed any of /proc/irq/*/threaded.
>
>I will provide any information needed to hunt this down.
>
>Rudo.
>  
>
Hi Igno,

I have the same troubles with O3 at home on my SMP machine, however
since the same kernel (2.6.8-rc2-mm2-O3) works flawlessly here at work
on a UP P4 I thought it to be SMP related.

I also tried booting my dual athlon with noapic but that did not solve
the problem.

I have not had enough time yet to file a proper bug report but seeing
this message I wanted to second it.

Are there any known SMP related problems with your patches?

and would my dmesg and .config from home be enough ?

kind regards,

Peter Zijlstra

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Rudo Thomas]

> > I just wanted to report that O3 (+preempt-timing-O2) locks up hard at
> > random occasions, even with voluntary-preempt=2 preempt=1 set at boot
> > time. I never changed any of /proc/irq/*/threaded.
> 
> could you check whether it works with all APIC options turned off in the
> .config?

It appears to. With APIC on, it crashed after 10 and 25 minutes. Without APIC,
it survived two hours.

Hope that helps.

Rudo.

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[David M]

Hello 

the xruns below happen pretty regular, however i dont think this is just 
related to the 02 patch, this happens with standard 2.6.7 kernel.  I assume 
it has something to do with drm and mga? 

Dave

XRUN: pcmC0D0p
 [<d48ef1f7>] snd_pcm_period_elapsed+0x2d7/0x430 [snd_pcm]
 [<c011046a>] scheduler_tick+0x20a/0x450
 [<d48a175a>] snd_ice1712_interrupt+0x1da/0x270 [snd_ice1712]
 [<c0118079>] generic_handle_IRQ_event+0x49/0x80
 [<c0105b0b>] do_IRQ+0x9b/0x140
 [<c0104234>] common_interrupt+0x18/0x20
 [<c010d734>] delay_tsc+0x14/0x20
 [<c01934c2>] __delay+0x12/0x20
 [<d4925218>] mga_do_dma_flush+0x48/0x1c0 [mga]
 [<d49262d9>] mga_dma_flush+0x109/0x130 [mga]
 [<d4921004>] mga_ioctl+0xe4/0x160 [mga]
 [<c015cce0>] sys_ioctl+0x100/0x270
 [<c01040c7>] syscall_call+0x7/0xb
XRUN: pcmC0D0p
 [<d48ef1f7>] snd_pcm_period_elapsed+0x2d7/0x430 [snd_pcm]
 [<c011c764>] update_process_times+0x44/0x50
 [<d48a175a>] snd_ice1712_interrupt+0x1da/0x270 [snd_ice1712]
 [<c011ca40>] do_timer+0xe0/0xf0
 [<c0118079>] generic_handle_IRQ_event+0x49/0x80
 [<c0105b0b>] do_IRQ+0x9b/0x140
 [<c0104234>] common_interrupt+0x18/0x20
 [<c010d734>] delay_tsc+0x14/0x20
 [<c01934c2>] __delay+0x12/0x20
 [<d4925218>] mga_do_dma_flush+0x48/0x1c0 [mga]
 [<d49262d9>] mga_dma_flush+0x109/0x130 [mga]
 [<d4921004>] mga_ioctl+0xe4/0x160 [mga]
 [<c015cce0>] sys_ioctl+0x100/0x270
 [<c01040c7>] syscall_call+0x7/0xb

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Thomas Charbonnel]

Ingo Molnar wrote :
> On Mon, 2 Aug 2004, Shane Shrybman wrote:
> 
> > Also, had to turn of parport in the config to get it to compile.
> > 
> > drivers/parport/share.c:77: unknown field `generic_enable_irq' specified
> > in initializer
> > drivers/parport/share.c:78: unknown field `generic_disable_irq'
> > specified in initializer
> 
> thx - i fixed this in -O3.
> 
> 	Ingo

In the end I found the cause of those latency spikes I was seeing every
~8 seconds. They are caused by ACPI. I tried to narrow the problem down,
and they're here whenever I compile ACPI in (even with no option and no
additional module) unless I specify acpi=off or acpi=ht (I don't have a
HT cpu, but it could be a clue as the ACPI interpreter is disabled in
this mode). I don't really hope that this will ever get fixed as my
toshiba laptop model is known to have a buggy bios WRT ACPI (I already
tried an alternate dsdt table that fixed a battery status reporting
issue, but the latency problem was still there).

Using your updated version of wli's preempt-timing patch on top of -O2,
here are the results :

On X startup :

Aug  2 15:40:08 satellite (X/4647): 1587us non-preemptible critical
section violated 1000 us preempt threshold starting at
voluntary_resched+0x3e/0x70 and ending at sys_ioctl+0xdd/0x2a0
Aug  2 15:40:08 satellite [<c010574e>] dump_stack+0x1e/0x30
Aug  2 15:40:08 satellite [<c011723e>] dec_preempt_count+0x3e/0x50
Aug  2 15:40:08 satellite [<c016956d>] sys_ioctl+0xdd/0x2a0
Aug  2 15:40:08 satellite [<c01051a5>] sysenter_past_esp+0x52/0x71


While accessing the file system (this one is very frequent):

Aug  2 15:32:24 satellite (bash/5298): 1095us non-preemptible critical
section violated 1000 us preempt threshold starting at
search_by_key+0x120/0x1140 and ending at voluntary_resched+0x1a/0x70
Aug  2 15:32:24 satellite [<c010574e>] dump_stack+0x1e/0x30
Aug  2 15:32:24 satellite [<c01171a6>] touch_preempt_timing+0x36/0x50
Aug  2 15:32:24 satellite [<c042856a>] voluntary_resched+0x1a/0x70
Aug  2 15:32:24 satellite [<c0158c44>] __getblk+0x44/0x70
Aug  2 15:32:24 satellite [<c01ae348>] search_by_key+0x78/0x1140
Aug  2 15:32:24 satellite [<c01af4bc>]
search_for_position_by_key+0xac/0x3f0
Aug  2 15:32:24 satellite [<c019e0c4>]
reiserfs_allocate_blocks_for_region+0x354/0x15b0
Aug  2 15:32:24 satellite [<c01a0c4c>] reiserfs_file_write+0x61c/0x8d0
Aug  2 15:32:24 satellite [<c0155e2f>] vfs_write+0xcf/0x140
Aug  2 15:32:24 satellite [<c0155f3f>] sys_write+0x3f/0x60
Aug  2 15:32:24 satellite [<c01051a5>] sysenter_past_esp+0x52/0x71


Mounting a reiserfs volume :

Aug  2 15:26:22 satellite (mount/2965): 2462us non-preemptible critical
section
violated 1000 us preempt threshold starting at
voluntary_resched+0x3e/0x70 and ending at voluntary_resched+0x1a/0x70
Aug  2 15:26:22 satellite [<c010574e>] dump_stack+0x1e/0x30
Aug  2 15:26:22 satellite [<c01171a6>] touch_preempt_timing+0x36/0x50
Aug  2 15:26:22 satellite [<c042856a>] voluntary_resched+0x1a/0x70
Aug  2 15:26:22 satellite [<c0158c44>] __getblk+0x44/0x70
Aug  2 15:26:22 satellite [<c0158cef>] __bread+0x1f/0x40
Aug  2 15:26:22 satellite [<c01b6d05>] journal_read+0xa5/0x520
Aug  2 15:26:22 satellite [<c01b7b8c>] journal_init+0x6ac/0x7f0
Aug  2 15:26:22 satellite [<c01a772c>] reiserfs_fill_super+0x27c/0x6e0
Aug  2 15:26:22 satellite [<c015d17e>] get_sb_bdev+0x13e/0x170
Aug  2 15:26:22 satellite [<c01a7bff>] get_super_block+0x2f/0x40
Aug  2 15:26:22 satellite [<c015d3f5>] do_kern_mount+0xa5/0x180
Aug  2 15:26:22 satellite [<c0174721>] do_new_mount+0x71/0xb0
Aug  2 15:26:22 satellite [<c0174e09>] do_mount+0x169/0x1b0
Aug  2 15:26:22 satellite [<c0175250>] sys_mount+0xb0/0x140
Aug  2 15:26:22 satellite [<c01051a5>] sysenter_past_esp+0x52/0x71



Another problem I had while trying the preempt-timing patch is that
using clock=pmtmr flooded my logs because the resolution of the detected
violations was 1ms, as shown below :

Aug  2 15:22:35 satellite (pdflush/43): 1000us non-preemptible critical
section
violated 1000 us preempt threshold starting at
voluntary_resched+0x3e/0x70 and ending at do_journal_end+0x4cf/0xb80
Aug  2 15:22:35 satellite [<c010574e>] dump_stack+0x1e/0x30
Aug  2 15:22:35 satellite [<c01171a6>] touch_preempt_timing+0x36/0x50
Aug  2 15:22:35 satellite [<c01b99ef>] do_journal_end+0x4cf/0xb80
Aug  2 15:22:35 satellite [<c01b8acc>] journal_end_sync+0x4c/0x90
Aug  2 15:22:35 satellite [<c01a514e>] reiserfs_sync_fs+0x5e/0xb0
Aug  2 15:22:35 satellite [<c015c7bc>] sync_supers+0xfc/0x110
Aug  2 15:22:35 satellite [<c013d911>] wb_kupdate+0x31/0x110
Aug  2 15:22:35 satellite [<c013e466>] __pdflush+0xd6/0x200
Aug  2 15:22:35 satellite [<c013e5b8>] pdflush+0x28/0x30
Aug  2 15:22:35 satellite [<c012d96a>] kthread+0xaa/0xb0
Aug  2 15:22:35 satellite [<c01032f5>] kernel_thread_helper+0x5/0x10
Aug  2 15:22:43 satellite printk: 5 messages suppressed.
(I also had 2000us, 3000us, and 4000us violations)

Using clock=tsc worked just fine.

Thanks for all the work you've done and are still doing on this,
Thomas

Re: [patch] voluntary-preempt-2.6.8-rc2-O2

[Paulo Marques]

Thomas Charbonnel wrote:
>....
> While accessing the file system (this one is very frequent):
> 
> Aug  2 15:32:24 satellite (bash/5298): 1095us non-preemptible critical
> section violated 1000 us preempt threshold starting at
> search_by_key+0x120/0x1140 and ending at voluntary_resched+0x1a/0x70
> Aug  2 15:32:24 satellite [<c010574e>] dump_stack+0x1e/0x30
> Aug  2 15:32:24 satellite [<c01171a6>] touch_preempt_timing+0x36/0x50
> Aug  2 15:32:24 satellite [<c042856a>] voluntary_resched+0x1a/0x70
> Aug  2 15:32:24 satellite [<c0158c44>] __getblk+0x44/0x70
> Aug  2 15:32:24 satellite [<c01ae348>] search_by_key+0x78/0x1140
> Aug  2 15:32:24 satellite [<c01af4bc>]
> search_for_position_by_key+0xac/0x3f0
> Aug  2 15:32:24 satellite [<c019e0c4>]
> reiserfs_allocate_blocks_for_region+0x354/0x15b0
> Aug  2 15:32:24 satellite [<c01a0c4c>] reiserfs_file_write+0x61c/0x8d0
                                          ^^^^^^^^
I remember some discussion on a "voluntary preempt" thread, about 
reiserfs being bad for latency.

You might search the archives for this, but as far as I remember, ext3 
was a better alternative, latency-wise.

-- 
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"