RE: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs

RE: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs

[Saksena, Manas]

Lee Revell wrote:
> On Tue, 2004-07-27 at 12:27, Ingo Molnar wrote:
>> i've uploaded -L2:
>> 
>> 
>> 
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2
>> -L2
>> 
>> the hardirq-redirection feature is activated via
>> voluntary-preemption=3 (default). All irqs except the timer irq are
>> redirected. (the timer irq needs to run from irq context - but it has
>> constant latency and constant frequency so it's not an issue. Soft
>> timers are executed from the timer softirq which is redirected and
>> hence preemptable.) 
>> 
>> this means that with this patch applied the 2.6 UP kernel is quite
>> close to being hard-RT capable (using controlled drivers and
>> workloads). All unbound-latency asynchronous workloads have been
>> unloaded into synchronous, schedulable process contexts - so nothing
>> can delay a high-prio RT task. (assuming we caught all the latencies.
>> Any remaining latency can be fixed with the existing methods.)
>> 
> The obvious next feature to add would be to make certain IRQs
> non-schedulable, like you would for an RT system.  For an
> audio system this would be just the soundcard interrupt (and timer as
> stated above). Then, while it still might not be hard-RT, it would
> blow away anything achievable on the other OS'es people do audio work
> with. 

Its really useful to have a thread per IRQ and to have an option to
run a particular IRQ handler in hardirq context. Then a system designer
or adminstrator can tune the priorities of different IRQ handler threads
depending on the latency requirements of a particular system. Scott's 
patch posted earlier (see link below) implements this -- this has proven

handy in many scenarios including, but not restricted to, audio
real-time 
performance. 

http://marc.theaimsgroup.com/?l=linux-kernel&m=109096903816850&w=2

Manas

Re: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs

[Carsten Rietzschel]

Hi all,

> i've uploaded -L2:
>
> http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc2-L2
>

While trying to combine voluntary-preempt-2.6.8-rc2-L2 with software suspend 2 
(swsusp2) I noticed that:
a) with voluntary-preempt = 3
      - writing suspend image to disk is very slow
      - resume fails !
b) with voluntary-preempt = 2
      - writing suspend image to disk is very slow
      - resume works but very slow
c) with voluntary-preempt = 1/0
      - all works as expected

It might be interesting for you to test it with suspend(1) / pm_disk (sorry, 
these don't work for me). I wonder if they'll also fail.

Regards,
Carsten

Re: [patch] voluntary-preempt-2.6.8-rc2-L2, preemptable hardirqs

[Felipe Alfaro Solana]

On Wed, 2004-07-28 at 22:59 +0200, Carsten Rietzschel wrote:

> It might be interesting for you to test it with suspend(1) / pm_disk (sorry, 
> these don't work for me). I wonder if they'll also fail.

For me, swsusp1/pmdisk works nicely with 0 <= voluntary_preempt <= 3,
even with CONFIG_PREEMPT.

Re: [patch] voluntary-preempt-2.6.8-rc2-L2 - modem dialup broken

[Carsten Rietzschel]

Hello,

I've found another problem w/ voluntary-preempt-2.6.8-rc2-L2:
my dialup connection with a modem is broken with voluntary-preempt=3.

With 
"echo 2 > /proc/sys/kernel/voluntary_preemption"
it works. All modem LEDs are blinking :)
Then 
"echo 3 > /proc/sys/kernel/voluntary_preemption"
-> the LEDs stop blinking after a few seconds. The connection times out.

The only log message I see when booting with voluntary-preempt on is this one:

Jul 29 10:57:51 linux irq event 4: bogus return value ffffffff
Jul 29 10:57:51 linux [<c01076ae>] dump_stack+0x1e/0x20
Jul 29 10:57:51 linux [<c0108b4b>] __report_bad_irq+0x2b/0x90
Jul 29 10:57:51 linux [<c0108be0>] report_bad_irq+0x30/0x40
Jul 29 10:57:51 linux [<c0108c82>] note_interrupt+0x92/0xa0
Jul 29 10:57:51 linux [<c0108ecb>] do_hardirq+0x11b/0x180
Jul 29 10:57:51 linux [<c012025c>] irqd+0x9c/0xc0
Jul 29 10:57:51 linux [<c012e25d>] kthread+0xad/0xc0
Jul 29 10:57:51 linux [<c01052b1>] kernel_thread_helper+0x5/0x14
Jul 29 10:57:51 linux handlers:
Jul 29 10:57:51 linux irq event 3: bogus return value ffffffff
Jul 29 10:57:51 linux [<c01076ae>] dump_stack+0x1e/0x20
Jul 29 10:57:51 linux [<c0108b4b>] __report_bad_irq+0x2b/0x90
Jul 29 10:57:51 linux [<c0108be0>] report_bad_irq+0x30/0x40
Jul 29 10:57:51 linux [<c0108c82>] note_interrupt+0x92/0xa0
Jul 29 10:57:51 linux [<c0108ecb>] do_hardirq+0x11b/0x180
Jul 29 10:57:51 linux [<c012025c>] irqd+0x9c/0xc0
Jul 29 10:57:51 linux [<c012e25d>] kthread+0xad/0xc0
Jul 29 10:57:51 linux [<c01052b1>] kernel_thread_helper+0x5/0x14

May be this related to the above problem.
Sorry for this inprecise description. Just ask me for more informations.

Regards,
Carsten

cat /proc/interrupts (without beeing online):
CPU0
  0:    5159722          XT-PIC  timer
  1:      14081          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  7:       2855          XT-PIC  VIA8233, uhci_hcd
  8:          4          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:     501556          XT-PIC  ohci1394, uhci_hcd
 11:      40604          XT-PIC  eth0, uhci_hcd, ehci_hcd
 14:      57086          XT-PIC  ide0
 15:         38          XT-PIC  ide1
NMI:          0
LOC:    5159632

cat /proc/interrupts (beeing online):
           CPU0
  0:    5248767          XT-PIC  timer
  1:      14803          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  3:    1945822          XT-PIC  serial
  7:       2893          XT-PIC  VIA8233, uhci_hcd
  8:          4          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:     512803          XT-PIC  ohci1394, uhci_hcd
 11:      40693          XT-PIC  eth0, uhci_hcd, ehci_hcd
 14:      57251          XT-PIC  ide0
 15:         38          XT-PIC  ide1
NMI:          0
LOC:    5248676
ERR:         21