UIO - interrupt performance

UIO - interrupt performance

[Douglas, Jim (Jim)]

We are contemplating porting a large number of device drivers to Linux.
The pragmatic solution is to keep them in user mode (using the UIO
framework) where possible ... they are written in C++ for a start.  

The obvious disadvantages of user mode device drivers are security /
isolation.  The main benefit is ease of development.  

Do you know what the *technical* disadvantages of this approach might
be? I am most concerned about possible impact on interrupt handling. 

For example, I assume the context switching overhead is higher, and that
interrupt latency is more difficult to predict?  

--jim douglas
Avaya UK, Registered in England and Wales under Registered Number
3049861, Registered Address: Avaya House, Cathedral Hill, Guildford,
Surrey, GU2 7YL.

Re: UIO - interrupt performance

[Ben Nizette]

On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote:
> We are contemplating porting a large number of device drivers to Linux.
> The pragmatic solution is to keep them in user mode (using the UIO
> framework) where possible ... they are written in C++ for a start.  
> 
> The obvious disadvantages of user mode device drivers are security /
> isolation.  The main benefit is ease of development.  
> 
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling. 
> 
> For example, I assume the context switching overhead is higher, and that
> interrupt latency is more difficult to predict?  

Userspace drivers certainly aren't first class citizens; uio and kernel
mode drivers generally aren't really interchangeable.

The technical disadvantages of userspace drivers are that you don't have
access to kernel subsystems, you can't run any userspace content in irq
context so everything needs to be scheduled before it can be dealt with.
A UIO driver still needs a kernel component to do acknowledge the
interrupt.  As such when you say "interrupt latency" you need to define
the end point.  A UIO driver will have it's in-kernel handler called
just as quickly as any other driver but the userspace app will need to
be scheduled before it receives notification that the IRQ has fired.

The technical advantage of a UIO driver is that devices which only need
to shift data don't have to double-handle it.  e.g. an ADC card doesn't
need to move ADC results from hardware to kernel, kernel to userspace,
it's just one fluid movement.

What kind of device drivers are you talking about?  They have to be of a
fairly specific flavour to fit in to a UIO model.  Linux isn't a
microkernel, userspace drivers are quite restricted in their power.

FWIW there is some (out of tree) kernel code written in C++, it can be
done but you have to avoid the standard c++ library which unfortunately
includes things like 'new'.

	--Ben.

Re: UIO - interrupt performance

[Ben Nizette]

On Mon, 2008-10-20 at 03:06 -0800, Nicholas Mc Guire wrote:
> >
> > On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote:
> > > We are contemplating porting a large number of device drivers to Linux.
> > > The pragmatic solution is to keep them in user mode (using the UIO
> > > framework) where possible ... they are written in C++ for a start.
> > >
> > > The obvious disadvantages of user mode device drivers are security /
> > > isolation.  The main benefit is ease of development.
> > >
> > > Do you know what the *technical* disadvantages of this approach might
> > > be? I am most concerned about possible impact on interrupt handling.
> > >
> > > For example, I assume the context switching overhead is higher, and that
> > > interrupt latency is more difficult to predict?
> >
> > Userspace drivers certainly aren't first class citizens; uio and kernel
> > mode drivers generally aren't really interchangeable.
> >
> > The technical disadvantages of userspace drivers are that you don't have
> > access to kernel subsystems, you can't run any userspace content in irq
> > context so everything needs to be scheduled before it can be dealt with.
> > A UIO driver still needs a kernel component to do acknowledge the
> > interrupt.  As such when you say "interrupt latency" you need to define
> > the end point.  A UIO driver will have it's in-kernel handler called
> > just as quickly as any other driver but the userspace app will need to
> > be scheduled before it receives notification that the IRQ has fired.
> >
> > The technical advantage of a UIO driver is that devices which only need
> > to shift data don't have to double-handle it.  e.g. an ADC card doesn't
> > need to move ADC results from hardware to kernel, kernel to userspace,
> > it's just one fluid movement.
> >
> > What kind of device drivers are you talking about?  They have to be of a
> > fairly specific flavour to fit in to a UIO model.  Linux isn't a
> > microkernel, userspace drivers are quite restricted in their power.
> >
> 
> are these claims based on benchmarks of a specific driver ? I only know
> of a singe UIO driver for a Hilscher CIF card and one for a SMX
> Cryptengine (I guess thats yours any way) but none for a AD/DIO card - if
> you know of such a driver I would be interested in seeing its performance.

When UIO was being discussed for inclusion, the example case being
thrown around was for such an ADC card.  They claimed to have seen
significant improvements in speed by avoiding the double-handling of
data.  Come to think of it, I can't see that this specific driver has
shown up...

But what kind of benchmarks do you want?  When I say "restricted in
their power" I mean more in a feature-set kind of way than a raw speed
way.  Userspace drivers can't plug in to kernel subsystems so can't, for
example, be SPI hosts or terminal devices or network hardware or
anything else which sits in the middle of a standard stack.  All they
can do is be notified of an interrupt and have direct access to a lump
of memory.

As I asked before, what's your use-case?  It tends to be fairly obvious
whether the hardware is suitable for a UIO-based driver or whether it's
going to have to live in kernel.

> 
> Also if you know of any simple UIO sample drivers that would also help.

As in examples of the userspace half?  Unfortunately uio-smx isn't ready
to fly thanks to some significant production delays but the userspace
half of the Hilscher CIF driver can be found at
http://www.osadl.org/projects/downloads/UIO/user/

	--Ben.

Re: UIO - interrupt performance

[Wolfgang Grandegger]

Ben Nizette wrote:
> On Mon, 2008-10-20 at 03:06 -0800, Nicholas Mc Guire wrote:
>>> On Mon, 2008-10-20 at 10:55 +0100, Douglas, Jim (Jim) wrote:
>>>> We are contemplating porting a large number of device drivers to Linux.
>>>> The pragmatic solution is to keep them in user mode (using the UIO
>>>> framework) where possible ... they are written in C++ for a start.
>>>>
>>>> The obvious disadvantages of user mode device drivers are security /
>>>> isolation.  The main benefit is ease of development.
>>>>
>>>> Do you know what the *technical* disadvantages of this approach might
>>>> be? I am most concerned about possible impact on interrupt handling.
>>>>
>>>> For example, I assume the context switching overhead is higher, and that
>>>> interrupt latency is more difficult to predict?
>>> Userspace drivers certainly aren't first class citizens; uio and kernel
>>> mode drivers generally aren't really interchangeable.
>>>
>>> The technical disadvantages of userspace drivers are that you don't have
>>> access to kernel subsystems, you can't run any userspace content in irq
>>> context so everything needs to be scheduled before it can be dealt with.
>>> A UIO driver still needs a kernel component to do acknowledge the
>>> interrupt.  As such when you say "interrupt latency" you need to define
>>> the end point.  A UIO driver will have it's in-kernel handler called
>>> just as quickly as any other driver but the userspace app will need to
>>> be scheduled before it receives notification that the IRQ has fired.
>>>
>>> The technical advantage of a UIO driver is that devices which only need
>>> to shift data don't have to double-handle it.  e.g. an ADC card doesn't
>>> need to move ADC results from hardware to kernel, kernel to userspace,
>>> it's just one fluid movement.
>>>
>>> What kind of device drivers are you talking about?  They have to be of a
>>> fairly specific flavour to fit in to a UIO model.  Linux isn't a
>>> microkernel, userspace drivers are quite restricted in their power.
>>>
>> are these claims based on benchmarks of a specific driver ? I only know
>> of a singe UIO driver for a Hilscher CIF card and one for a SMX
>> Cryptengine (I guess thats yours any way) but none for a AD/DIO card - if
>> you know of such a driver I would be interested in seeing its performance.
> 
> When UIO was being discussed for inclusion, the example case being
> thrown around was for such an ADC card.  They claimed to have seen
> significant improvements in speed by avoiding the double-handling of
> data.  Come to think of it, I can't see that this specific driver has
> shown up...
> 
> But what kind of benchmarks do you want?  When I say "restricted in
> their power" I mean more in a feature-set kind of way than a raw speed
> way.  Userspace drivers can't plug in to kernel subsystems so can't, for
> example, be SPI hosts or terminal devices or network hardware or
> anything else which sits in the middle of a standard stack.  All they
> can do is be notified of an interrupt and have direct access to a lump
> of memory.
> 
> As I asked before, what's your use-case?  It tends to be fairly obvious
> whether the hardware is suitable for a UIO-based driver or whether it's
> going to have to live in kernel.
> 
>> Also if you know of any simple UIO sample drivers that would also help.
> 
> As in examples of the userspace half?  Unfortunately uio-smx isn't ready
> to fly thanks to some significant production delays but the userspace
> half of the Hilscher CIF driver can be found at
> http://www.osadl.org/projects/downloads/UIO/user/

As I see it, mainly the license conditions attract people to use UIO.
Performance is not that important.

Wolfgang.

Re: UIO - interrupt performance

[Ben Nizette]

On Tue, 2008-10-21 at 08:57 +0200, Wolfgang Grandegger wrote:
> Ben Nizette wrote:
> > 
> > As in examples of the userspace half?  Unfortunately uio-smx isn't ready
> > to fly thanks to some significant production delays but the userspace
> > half of the Hilscher CIF driver can be found at
> > http://www.osadl.org/projects/downloads/UIO/user/
> 
> As I see it, mainly the license conditions attract people to use UIO.
> Performance is not that important.
> 

Ohw god I hope not.  If people want to keep their stuff proprietary they
can supply binary-only modules a la nvidia.  Thankfully such nonsense is
fairly uncommon these days.

UIO is not a set of hooks for general userspace drivers, it can't
replace 99% of kernel drivers.  It exists to allow easy and
high-performance interfacing to a particular family of devices - those
which simply need to shift data around and have an interrupt telling you
when they're done.

	--Ben.

Re: UIO - interrupt performance

[Christian SCHWARZ]

Hi Jim,

> The obvious disadvantages of user mode device drivers are security /
> isolation. 
without going back to the endless discussion of micro-kernels vs
monolithic OS's, the main *advantage* is security and isolation: faults
in the driver will not or to a lesser degree impact the kernel and thus
overall system stability. And drivers are isolated from each other, if
the OS is doing at least an OK job.

> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling. 
The main obstacles for driver development in my opinion are:
- additional context switches (user -> user, user <-> kernel)
- you need to have a decent user <-> kernel interface, since partial INT
handling must be done in kernel mode
- a "Device driver framework" generally helps having clean drivers and
reduces code duplication and "spaghetti code" and especially reduce
context switching times

Apart from that the kernel might need to implement mechanisms like
"priority inheritance" or other scheduling policies in order to make
sure the user mode interrupt handler gets to run (with a minimal delay).

//Christian

Re: UIO - interrupt performance

[Marco Stornelli]

I quite agree with Ben and Christian. I think UIO drivers are usable for
simple devices, I think they aren't mature (will it ever be?) to use it
with complicated devices or with strict requirement.

Regards,

Douglas, Jim (Jim) ha scritto:
> We are contemplating porting a large number of device drivers to Linux.
> The pragmatic solution is to keep them in user mode (using the UIO
> framework) where possible ... they are written in C++ for a start.  
> 
> The obvious disadvantages of user mode device drivers are security /
> isolation.  The main benefit is ease of development.  
> 
> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling. 
> 
> For example, I assume the context switching overhead is higher, and that
> interrupt latency is more difficult to predict?  
> 
> --jim douglas
> Avaya UK, Registered in England and Wales under Registered Number
> 3049861, Registered Address: Avaya House, Cathedral Hill, Guildford,
> Surrey, GU2 7YL.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: UIO - interrupt performance

[Paul Mundt]

On Mon, Oct 20, 2008 at 01:55:41PM +0200, Marco Stornelli wrote:
> I quite agree with Ben and Christian. I think UIO drivers are usable for
> simple devices, I think they aren't mature (will it ever be?) to use it
> with complicated devices or with strict requirement.
> 
This is a party line that has been parroted around a lot but doesn't
really have a lot of validity. UIO drivers are usable for situations
where the kernel-side handling of the device can be trivialized but still
remains a necessary component in the device support (other than IRQ
control, there is also the issue of setting up buffers and so on).

A good example of this is platforms that push their multimedia codecs and
blocks down through UIO. The reason for this is that there is a lot of
complexity, requisite support code, and general overhead associated with
supporting these blocks, most of which simply does not belong anywhere in
the kernel, even though the kernel still has to do some degree of device
support. UIO drivers are second class citizens in general, but the
argument that they only apply to simple devices is simply incorrect.

Things like uio_pdrv_genirq exist today which already allow for interrupt
control through userspace, for example. You can grep for the uio_pdrv_genirq
in-tree users to see examples of how this is used in the aforementioned
case today.

Re: UIO - interrupt performance

[Bill Gatliff]

Marco Stornelli wrote:
> I quite agree with Ben and Christian. I think UIO drivers are usable for
> simple devices, I think they aren't mature (will it ever be?) to use it
> with complicated devices or with strict requirement.

I disagree.  Completely.

I recall seeing a report from the Gelato project, where they reimplemented an
IDE driver under UIO.  IIRC, their test results showed at least 80% of the
in-kernel performance--- and this was a very early UIO implementation, I would
guess that things are much improved since then.  I know that IDE isn't a USBH,
but it isn't a GPIO LED, either.  :)

If you are concerned about timeliness of execution, then if you have never heard
of POSIX.1b then you shouldn't be writing Linux code anyway.  But if you do use
the features that POSIX.1b gives you, then I haven't found UIO to be objectionable.

From a performance standpoint, the major differences between UIO vs. in-kernel
are (a) a _possible_ additional context switch at each interrupt, to transfer
control back to the userspace responder, and (b) the elimination of a syscall to
push data through an in-kernel interface back to the device.  Only your own
testing with your own hardware and application can tell you if that's a net
improvement or regression and where--- if anywhere--- you take the hit.

The general upsides with UIO are huge: you can debug your driver with gdb, and
you can bind your driver tightly to your application if it makes sense to do so.
 Every i/o action is potentially zero-copy straight into the correct data
structures, for example.  For some workloads, that puts UIO way ahead of an
in-kernel driver without the complexity of mmap().

As an aside, if you really need an interface that resembles a device node then
you can emulate that in userspace with a FIFO.  That lets you put the driver in
a standalone program if you like, and other user applications can't tell the
difference between that and a true device node.  (They can figure it out if they
need to, but if they just are using open/close/read/write then they don't care).

The social downside to UIO is that you'll never get your driver(s) mainlined,
since Linux-the-kernel doesn't run in userspace.  :)

Put simply, you can't dismiss UIO lightly unless you haven't worked with or
reviewed the code behind it.



b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: UIO - interrupt performance

[Marco Stornelli]

As I said I think UIO drivers are a "young feature" from kernel point of
view but I haven't problems to use it. Jim, however, was talking about
to do a complete porting of drivers. I don't know if it'd be a good
idea. UIO drivers, however, has been inserted mainly for one reason: the
problem with GPL, so I prefer, but it's only my opinion, at least for
now, to write a "classic" driver if there aren't GPL problems.

Bill Gatliff ha scritto:
> Marco Stornelli wrote:
>> I quite agree with Ben and Christian. I think UIO drivers are usable for
>> simple devices, I think they aren't mature (will it ever be?) to use it
>> with complicated devices or with strict requirement.
> 
> I disagree.  Completely.
> 
> I recall seeing a report from the Gelato project, where they reimplemented an
> IDE driver under UIO.  IIRC, their test results showed at least 80% of the
> in-kernel performance--- and this was a very early UIO implementation, I would
> guess that things are much improved since then.  I know that IDE isn't a USBH,
> but it isn't a GPIO LED, either.  :)
> 
> If you are concerned about timeliness of execution, then if you have never heard
> of POSIX.1b then you shouldn't be writing Linux code anyway.  But if you do use
> the features that POSIX.1b gives you, then I haven't found UIO to be objectionable.
> 
>>From a performance standpoint, the major differences between UIO vs. in-kernel
> are (a) a _possible_ additional context switch at each interrupt, to transfer
> control back to the userspace responder, and (b) the elimination of a syscall to
> push data through an in-kernel interface back to the device.  Only your own
> testing with your own hardware and application can tell you if that's a net
> improvement or regression and where--- if anywhere--- you take the hit.
> 
> The general upsides with UIO are huge: you can debug your driver with gdb, and
> you can bind your driver tightly to your application if it makes sense to do so.
>  Every i/o action is potentially zero-copy straight into the correct data
> structures, for example.  For some workloads, that puts UIO way ahead of an
> in-kernel driver without the complexity of mmap().
> 
> As an aside, if you really need an interface that resembles a device node then
> you can emulate that in userspace with a FIFO.  That lets you put the driver in
> a standalone program if you like, and other user applications can't tell the
> difference between that and a true device node.  (They can figure it out if they
> need to, but if they just are using open/close/read/write then they don't care).
> 
> The social downside to UIO is that you'll never get your driver(s) mainlined,
> since Linux-the-kernel doesn't run in userspace.  :)
> 
> Put simply, you can't dismiss UIO lightly unless you haven't worked with or
> reviewed the code behind it.
> 
> 
> 
> b.g.

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: UIO - interrupt performance

[Alessio Igor Bogani]

Hi All,

Sorry for my (very) bad english.

2008/10/21 Marco Stornelli <marco.stornelli@coritel.it>:
[...]
> idea. UIO drivers, however, has been inserted mainly for one reason: the
> problem with GPL, so I prefer, but it's only my opinion, at least for
> now, to write a "classic" driver if there aren't GPL problems.

No, that isn't the main objective of the UIO Authors.

AFAIK They want achieve:

1) Fast prototyping for device drivers
2) Easy and fast debug
3) Avoid "fast and furious" changes of the internal kernel interfaces
for their drivers

Ciao,
Alessio

Re: UIO - interrupt performance

[Marco Stornelli]

I could agree, but "the facto" due to UIO license condition, a company
often uses UIO drivers, regardless performance, debug, etc, only as not
to public the code under GPL.

Alessio Igor Bogani ha scritto:
> Hi All,
> 
> Sorry for my (very) bad english.
> 
> 2008/10/21 Marco Stornelli <marco.stornelli@coritel.it>:
> [...]
>> idea. UIO drivers, however, has been inserted mainly for one reason: the
>> problem with GPL, so I prefer, but it's only my opinion, at least for
>> now, to write a "classic" driver if there aren't GPL problems.
> 
> No, that isn't the main objective of the UIO Authors.
> 
> AFAIK They want achieve:
> 
> 1) Fast prototyping for device drivers
> 2) Easy and fast debug
> 3) Avoid "fast and furious" changes of the internal kernel interfaces
> for their drivers
> 
> Ciao,
> Alessio
> 

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: UIO - interrupt performance

[Ben Nizette]

On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote:
> I could agree, but "the facto" due to UIO license condition, a company
> often uses UIO drivers, regardless performance, debug, etc, only as not
> to public the code under GPL.

It sounds to me like you think that driver authors can sit down and
decide whether they want to implement their driver in userspace or
kernel space.  For 99% of drivers that's simply not true.  You  *cannot*
write userspace drivers for most hardware, the hooks just aren't
available.  UIO is Userspace I/O, not a set of general hooks for
userspace drivers.

If people want drivers not under the GPL then they can distribute a
binary-only module (though thank $DEITY there aren't many of those
left).  Userspace I/O exists to provide good performance interfacing to
a family of devices - those which exist just to shuffle data around and
have an interrupt to tell you when they're done.

Do you have any example of a userspace i/o driver which exists to get
around licencing constraints?

	--Ben.

Re: UIO - interrupt performance

[Marco Stornelli]

No I don't think you can decide kernel or user space, indeed you can
read my previous posts, I quite agree with you, I meant the same to Bill
Gatliff.

Ben Nizette ha scritto:
> On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote:
>> I could agree, but "the facto" due to UIO license condition, a company
>> often uses UIO drivers, regardless performance, debug, etc, only as not
>> to public the code under GPL.
> 
> It sounds to me like you think that driver authors can sit down and
> decide whether they want to implement their driver in userspace or
> kernel space.  For 99% of drivers that's simply not true.  You  *cannot*
> write userspace drivers for most hardware, the hooks just aren't
> available.  UIO is Userspace I/O, not a set of general hooks for
> userspace drivers.
> 
> If people want drivers not under the GPL then they can distribute a
> binary-only module (though thank $DEITY there aren't many of those
> left).  Userspace I/O exists to provide good performance interfacing to
> a family of devices - those which exist just to shuffle data around and
> have an interrupt to tell you when they're done.
> 
> Do you have any example of a userspace i/o driver which exists to get
> around licencing constraints?
> 
> 	--Ben.
> 
> 

-- 
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it

marco.stornelli@coritel.it
+39 06 72582838

Re: UIO - interrupt performance

[Wolfgang Grandegger]

Ben Nizette wrote:
> On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote:
>> I could agree, but "the facto" due to UIO license condition, a company
>> often uses UIO drivers, regardless performance, debug, etc, only as not
>> to public the code under GPL.
> 
> It sounds to me like you think that driver authors can sit down and
> decide whether they want to implement their driver in userspace or
> kernel space.  For 99% of drivers that's simply not true.  You  *cannot*
> write userspace drivers for most hardware, the hooks just aren't
> available.  UIO is Userspace I/O, not a set of general hooks for
> userspace drivers.

I known, fortunately it's not that simple or even feasible. Image a
network driver with I/O multiplexing used by various processes.

> If people want drivers not under the GPL then they can distribute a
> binary-only module (though thank $DEITY there aren't many of those
> left).  Userspace I/O exists to provide good performance interfacing to

That's *not* an option, please read the GPL license conditions. At least
it's legal gray area. Note that it's not my intention to start a
discussion on that.

> a family of devices - those which exist just to shuffle data around and
> have an interrupt to tell you when they're done.
> 
> Do you have any example of a userspace i/o driver which exists to get
> around licencing constraints?

There will be plenty sooner than later. What you can do currently with
UIO is very limited.

Wolfgang.

Re: UIO - interrupt performance

[Bill Gatliff]

Wolfgang Grandegger wrote:
> Ben Nizette wrote:
>> On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote:
>>> I could agree, but "the facto" due to UIO license condition, a company
>>> often uses UIO drivers, regardless performance, debug, etc, only as not
>>> to public the code under GPL.
>> It sounds to me like you think that driver authors can sit down and
>> decide whether they want to implement their driver in userspace or
>> kernel space.  For 99% of drivers that's simply not true.  You  *cannot*
>> write userspace drivers for most hardware, the hooks just aren't
>> available.  UIO is Userspace I/O, not a set of general hooks for
>> userspace drivers.
> 
> I known, fortunately it's not that simple or even feasible. Image a
> network driver with I/O multiplexing used by various processes.

Actually, UIO is pretty useful for that when combined with tun/tap.

> That's *not* an option, please read the GPL license conditions. At least
> it's legal gray area. Note that it's not my intention to start a
> discussion on that.

Then I will only contradict you, and not cite my supporting evidence.  :)


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: UIO - interrupt performance

[Thomas Petazzoni]

Le Mon, 20 Oct 2008 10:55:17 +0100,
"Douglas, Jim (Jim)" <jdouglas@avaya.com> a écrit :

> Do you know what the *technical* disadvantages of this approach might
> be? I am most concerned about possible impact on interrupt handling. 
> 
> For example, I assume the context switching overhead is higher, and
> that interrupt latency is more difficult to predict?  

There was a presentation on UIO in embedded systems at the latest
Embedded Linux Conference in April. The presentation includes a small
analysis of UIO's overhead with regard to interrupt latency. See
http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf

Sincerly,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com

Re: UIO - interrupt performance

[Bill Gatliff]

Thomas Petazzoni wrote:
> 
> There was a presentation on UIO in embedded systems at the latest
> Embedded Linux Conference in April. The presentation includes a small
> analysis of UIO's overhead with regard to interrupt latency. See
> http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf

Bummer, on p. 20 it doesn't describe how the latency was measured.  It also
doesn't compare in-kernel measurements with equivalent UIO measurements.

I don't particularly care what the interrupt latency is, if what is being
measured is the time between when the interrupt is signaled to the CPU and the
point at which the request_irq()-registered handler runs.

Rather, most of the time I care more about how long it takes the kernel to wake
up the process that's blocked in a wait_for_completion(), because I do most of
my work outside of interrupt handlers (a characteristic of the devices and
workloads I deal with, ymmv).  In that case, the difference between in-kernel
and UIO gets pretty small because the kernel activities at each interrupt are
very similar, perhaps differing only by some cache activity.

Glad they mention SCHED_[FIFO|RR], though.  Without those, you're in for a
pretty unpleasant UIO experience.



b.g.
-- 
Bill Gatliff
bgat@billgatliff.com