The realtime preemption mini-summit

Posted Sep 28, 2009 22:00 UTC (Mon) by nix (subscriber, #2304)
Parent article: The realtime preemption mini-summit

SYSV IPC is best avoided.

Not just in realtime situations, of course.

A realtime idle loop. There is the usual tension there between preserving the best response time and minimizing power consumption.

Liunx can do infinite loops faster than anything else!

Supporting hardware-assisted operations - things like onboard cryptographic acceleration hardware.

Well, that's an interesting question, really. I've got a couple of machines with Geode CPUs now, and these have AES hardware acceleration. Some of the BSDs provide an interface that allows OpenSSL to use this, but as far as I can tell Linux does not. There's support for the Geode in the crypto layer, but this doesn't seem to be made available to userspace, so if you do your crypto in userspace (say, ssh), you're stuck using the CPU, which is much slower at this sort of thing.

I saw some patches a long time ago adding a BSD-style /dev/crypto, but then I lost them again...

The realtime preemption mini-summit

Posted Sep 28, 2009 22:35 UTC (Mon) by cortana (subscriber, #24596) [Link] (1 responses)

ISTR the Geode's AES encryption acceleration is accessed with particular instructions. No special privilege required. But I may be wrong.

The realtime preemption mini-summit

Posted Sep 29, 2009 9:20 UTC (Tue) by nix (subscriber, #2304) [Link]

Oh right. My ignorance is showing, so I'll go and correct that before saying anything else (and add a comment here once I know one way or the other).

The realtime preemption mini-summit

Posted Sep 28, 2009 22:42 UTC (Mon) by flewellyn (subscriber, #5047) [Link] (5 responses)

>> SYSV IPC is best avoided.

>Not just in realtime situations, of course.

Tell that to the PostgreSQL people. They use SYSV shared memory and semaphores in the database. It's quite efficient and works well.

Of course, an RDBMS is not a realtime application, but you claimed that it should be avoided in other situations as well.

The realtime preemption mini-summit

Posted Sep 29, 2009 9:21 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

Yes. I don't really know why databases use SysV SHM: the API for all the SysV stuff is so cracksmoking and unpleasant and non-Unixlike. I suppose POSIX shared memory functions didn't exist when PostgreSQL was young, and mmap() of /dev/null wasn't very portable at that point... so maybe it's just history.

The realtime preemption mini-summit

Posted Sep 29, 2009 14:58 UTC (Tue) by flewellyn (subscriber, #5047) [Link]

Well, the SysV stuff for a lot of things is unpleasant to work with. Still, it does work.

POSIX shmem in PostgreSQL

Posted Sep 29, 2009 19:50 UTC (Tue) by alvherre (subscriber, #18730) [Link] (2 responses)

It's not just history. In fact, a patch was posted to add support for POSIX shmem, but as it turns out, the POSIX API is not complete enough for PostgreSQL's purposes. See here, for instance: http://archives.postgresql.org/pgsql-patches/2007-02/msg0...

POSIX shmem in PostgreSQL

Posted Sep 29, 2009 22:47 UTC (Tue) by alvherre (subscriber, #18730) [Link]

BTW, mmap does not work either.

POSIX shmem in PostgreSQL

Posted Sep 30, 2009 15:14 UTC (Wed) by nix (subscriber, #2304) [Link]

Oh, curses. We need a POSIX syscall that does what lsof/fuser do, really.