[Xenomai-core] kconfig help questions

[Xenomai-core] kconfig help questions

[Jim Cromie]

Going thru xenomai Kconfig again, some observations/uncertainties came up.
I'll make a patch, given feedback.

XENO_OPT_TIMING_PERIODIC

"Aperiodic mode provides for non-constant delays between timer ticks,"

the wording here (non-constant delays) left me momentarily wondering
if _APERIODIC was bad (this, despite the use of 'provides'). 
Maybe "sub-tick delays" makes some sense ..

XENO_OPT_SHIRQ_LEVEL

Are there any decent estimates or examples of the latency / jitter increases
if this is enabled ?  Is it highly cpu or chipset dependent ?
I presume /proc/interrupts is the place to look to see if you might need it,
iff any of the devices of interest are shared.
my laptop shows sharing, my soekris does not

  3:          5          XT-PIC  ehci_hcd:usb1, ohci1394
  4:          0          XT-PIC  uhci_hcd:usb6
  7:     708975          XT-PIC  ipw2200, ehci_hcd:usb2, uhci_hcd:usb7
  8:          1          XT-PIC  rtc
  9:     437509          XT-PIC  acpi, Intel 82801DB-ICH4, Intel 
82801DB-ICH4 Modem, ohci_hcd:usb3, ohci_hcd:usb4, uhci_hcd:usb5, yenta, eth0

# cat /proc/interrupts
           CPU0
  0:   13148086          XT-PIC  timer
  2:          0          XT-PIC  cascade
  4:      33084          XT-PIC  serial
  8:          4          XT-PIC  rtc
 10:     337134          XT-PIC  eth0
 11:     926639          XT-PIC  ndiswrapper
 14:         11          XT-PIC  ide0
NMI:          0


XENO_OPT_SHIRQ_EDGE

does this only apply to ISA bus ?

XENO_SKIN_NATIVE

will add module name

XENO_OPT_NATIVE_INTR

Note that the preferred
way of implementing generic drivers usable across all Xenomai
interfaces is defined by the Real-Time Driver Model (RTDM).

It doesnt say theyre (in)?compatible, should it ?


SUMMARY

Id like to see estimates of the latency costs associated with each choice,
where its practical to do so (given the current unknowables, like 
variations across
cpus, chipsets etc).  I recognize that such numbers are the hoped-for
end result of the xenomai-data ML, and perhaps nothing real can be said
yet (or ever) in Kconfig, except in (overly?) broad statements.

Re: [Xenomai-core] kconfig help questions

[Philippe Gerum]

Jim Cromie wrote:
> 
> Going thru xenomai Kconfig again, some observations/uncertainties came up.
> I'll make a patch, given feedback.
> 
> XENO_OPT_TIMING_PERIODIC
> 
> "Aperiodic mode provides for non-constant delays between timer ticks,"
> 
> the wording here (non-constant delays) left me momentarily wondering
> if _APERIODIC was bad (this, despite the use of 'provides'). Maybe 
> "sub-tick delays" makes some sense ..
> 

The fundamental issue is that aperiodic mode is tick-less, in the sense 
that it does not define any constant period value; in this respect, 
introducing the sub-tick notion would not make much sense. What about 
"arbitrary delays" instead?

> XENO_OPT_SHIRQ_LEVEL
> 
> Are there any decent estimates or examples of the latency / jitter 
> increases
> if this is enabled ?  Is it highly cpu or chipset dependent ?

More cache misses since we need to scan the entire chain of handlers, 
and obviously more processing from the various handlers.

> I presume /proc/interrupts is the place to look to see if you might need 
> it,
> iff any of the devices of interest are shared.
> my laptop shows sharing, my soekris does not
> 
>  3:          5          XT-PIC  ehci_hcd:usb1, ohci1394
>  4:          0          XT-PIC  uhci_hcd:usb6
>  7:     708975          XT-PIC  ipw2200, ehci_hcd:usb2, uhci_hcd:usb7
>  8:          1          XT-PIC  rtc
>  9:     437509          XT-PIC  acpi, Intel 82801DB-ICH4, Intel 
> 82801DB-ICH4 Modem, ohci_hcd:usb3, ohci_hcd:usb4, uhci_hcd:usb5, yenta, 
> eth0
> 
> # cat /proc/interrupts
>           CPU0
>  0:   13148086          XT-PIC  timer
>  2:          0          XT-PIC  cascade
>  4:      33084          XT-PIC  serial
>  8:          4          XT-PIC  rtc
> 10:     337134          XT-PIC  eth0
> 11:     926639          XT-PIC  ndiswrapper
> 14:         11          XT-PIC  ide0
> NMI:          0
> 

It's more a sharing in the RT sense, so you likely would not have to 
share the IRQs with the non-RT Linux side altogether, since this adds 
more complexity to the picture (specifically: how to share the ack/eoi 
cycle between the RT and non-RT sides).

> 
> XENO_OPT_SHIRQ_EDGE
> 
> does this only apply to ISA bus ?
> 

Not exclusively. x86-wise, the IO-APIC is both capable of handling edge 
and level interrupts.

> XENO_SKIN_NATIVE
> 
> will add module name
> 
> XENO_OPT_NATIVE_INTR
> 
> Note that the preferred
> way of implementing generic drivers usable across all Xenomai
> interfaces is defined by the Real-Time Driver Model (RTDM).
> 
> It doesnt say theyre (in)?compatible, should it ?
> 

They are not. The native interrupt support is providing basic access to 
the core interrupt layer RTDM does use for its own purpose too.

> 
> SUMMARY
> 
> Id like to see estimates of the latency costs associated with each choice,
> where its practical to do so (given the current unknowables, like 
> variations across
> cpus, chipsets etc).  I recognize that such numbers are the hoped-for
> end result of the xenomai-data ML, and perhaps nothing real can be said
> yet (or ever) in Kconfig, except in (overly?) broad statements.
> 

IMO, it seems rather difficult to state something sensible regarding the 
latency introduced by IRQ sharing in the Kconfig help strings, since it 
would basically depend on what the shared IRQ handlers are doing in the 
first place.

> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.