[PATCH] xfree86: Use SA_SIGINFO if available for SIGIO handlers

[Mark Kettenis]

> From: Adam Jackson <ajax at nwnk.net>
> Date: Tue, 17 Nov 2009 15:57:46 -0500
>
> On Tue, 2009-11-10 at 21:15 +0100, Mark Kettenis wrote:
> > > From: Adam Jackson <ajax at redhat.com>
> > > Date: Tue, 10 Nov 2009 15:03:31 -0500
> > >=20
> > > This one's slightly subtle, the fcntl(F_SETSIG) is required for ->si_fd
> > > to actually be filled in correctly, at least on Linux.  I know this are=
> a
> > > has been sensitive to platform variation in the past, so I'd appreciate
> > > a second look from Solaris / BSD / Hurd people.
> >=20
> > Alas, OpenBSD doesn't have si_fd.  So if you really want to go this
> > route, you'll need to add an additional configure check for it.
> 
> Harsh!

Heh, well, I guess I should look at implementing this properly in the
OpenBSD kernel, but that doesn't really buy you anything until OpenBSD
4.7 gets released on the 1st of May next year.

> > > siginfo_t gives us the file descriptor that raised the signal directly,
> > > so we don't need to select() for it.  This gets evdev event processing
> > > down to exactly one syscall in the common case.
> >=20
> > Is that an optimizition that's really worth the added complexity?
> 
> Seems straightforward to me.  I just wrote it because it's clearly
> correct.

But the #ifdef's lead to more code paths that need to tested and
maintained.

> But hey, why guess when you could measure.  This:
> 
> http://ajax.fedorapeople.org/ten-million-selects.c
> 
> in a RHEL5.4 32-bit kvm guest (Fedora 12 host, Intel Core 2 Duo at
> 2.6GHz) runs about this fast:
> 
> % time ./ten-million-selects
> ./ten-million-selects  1.35s user 4.28s system 94% cpu 5.981 total
> 
> So, about 1500 cycles per select call, and if your mouse was absolutely
> screaming events at you, you'd max out at something like a thousand per
> second, which'd come to about half a millisecond.  If you're a gamer,
> you might pretend to notice that.  But, that's a fairly fast machine;
> how far down do you want to scale?  Assuming identical syscall code
> paths (which is a bit spurious, I know) on a 300MHz chip that'd be 5ms,
> which is starting to get into losing frames territory.

So this may be relevant but marginally so.  I'll leave it up to you
whether you want to pursue this further.  Feel free to bother me if
you want to have things tested on OpenBSD.

> I'd have tried OpenBSD 4.6 but it failed to boot once installed and I
> couldn't be bothered to figure out if that was a kvm bug or not.

It is, but then I'm biased ;)

Anyway, on a 2 GHz Intel Core 2 Duo, OpenBSD 4.6-current I get:

$ time ./ten-million-selects
    0m9.74s real     0m1.38s user     0m8.34s system

So roughly the same as your figures.