Jim Cromie wrote:
Going thru xenomai Kconfig again, some observations/uncertainties came up.
I'll make a patch, given feedback.
"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?
Are there any decent estimates or examples of the latency / jitter
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
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,
# cat /proc/interrupts
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
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).
does this only apply to ISA bus ?
Not exclusively. x86-wise, the IO-APIC is both capable of handling edge
and level interrupts.
will add module name
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.
Id like to see estimates of the latency costs associated with each choice,
where its practical to do so (given the current unknowables, like
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
Xenomai-core mailing list
Xenomai-core mailing list