?

Log in

No account? Create an account
Dear Lazyweb, .... Linux::AIO on ia64, hppa, and alpha - brad's life — LiveJournal [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Dear Lazyweb, .... Linux::AIO on ia64, hppa, and alpha [Apr. 17th, 2005|11:31 am]
Brad Fitzpatrick
[Tags|, , ]

If anybody can get the CPAN module Linux::AIO to build (and test correctly) on one or all of IA64, Alpha, and HPPA, I'll buy you a beer and a permanent account. Here's the Debian buildd results so you can see how it's failing. (You don't need to use Debian, though... I'll take contest entries in raw diff format against the Linux::AIO distribution. Offer not valid for Florida residents or where prohibited by law. :P)

And/or, modify Perlbal to use File::FDpasser to portably do async stats/opens/closes in a child process. Won't be as fast, but it'd work on FreeBSD, whose users are currently unable to use Perlbal in webserver mode (and thus unable to use MogileFS).

But if FDpasser is slower than Linux::AIO by enough to matter, we can make Perlbal's core use Linux::AIO on Linux and FDpasser everywhere else.
LinkReply

Comments:
[User Picture]From: caladri
2005-04-17 07:22 pm (UTC)

rough try

(Reply) (Thread)
[User Picture]From: brad
2005-04-17 07:55 pm (UTC)

Re: rough try

If only it were that easy. :-)

(For others: we tried to get this to work for about an hour, but Debian on ia-64 has other issues, apparently.....)
(Reply) (Parent) (Thread)
[User Picture]From: caladri
2005-04-17 07:57 pm (UTC)

Re: rough try

holy crap linux is a steaming pile of shit!
(Reply) (Parent) (Thread)
[User Picture]From: aaronlehmann
2005-04-17 09:49 pm (UTC)
I hacked up something to make it pass the tests on IA64. Use it at your own risk. It still builds and passes the tests on i386. The patch is against 1.4-1.

I couldn't see why it uses the syscall macros to call directly into the kernel instead of using the libc wrappers. Perhaps performance reasons? This was causing problems at least on IA64, so I made it use the libc functions instead. If this is a problem, the _syscall gunk could be wrapped in some ifdefs. This might have fixed stuff on HPPA or alpha as well (when combined with caladri's patch).

The other problem is ia64's lack of a clone() syscall. For some reason, it uses clone2() instead. See this thread.
(Reply) (Thread)
[User Picture]From: brad
2005-04-17 11:42 pm (UTC)
It's not performance reasons... there's some bizarre reason, I think with the interaction of libc stuff after you've cloned.

Thanks for the pointer on clone2 and how to use it, though.

Did you do this on Debian or something else?

I'm busy the rest of the day on some slides, but I'll reply back here when I work on this again.
(Reply) (Parent) (Thread)
[User Picture]From: aaronlehmann
2005-04-18 12:11 am (UTC)
I used Debian.

I'd look at restoring the syscalls but that really seems to be the wrong way to go. It's pretty fundamentally unportable. Some of the calling conventions look like they would be incorrect on many architectures, i.e. the assumption that pread64 takes the offset in two 32-bit words.

It probably more makes sense to try and fix or work around the libc interaction, which I couldn't do without more information. pthreads would be a lot more likely than clone() to work without strange side effects, if they're usable in a perl module.
(Reply) (Parent) (Thread)
[User Picture]From: aaronlehmann
2005-04-18 12:20 am (UTC)
(hm, can't seem to reply to my not-yet-unscreened comment.)

Alternatively, what about rewriting it to use POSIX AIO routines? From the documentation:

This module implements asynchronous i/o using the means available to linux
- clone. It does not hook into the POSIX aio_* functions because linux
does not yet support these in the kernel (and even if, it would only allow
aio_read and write, not open and stat).

Instead, in this module a number of (non-posix) threads are started that
execute your read/writes and signal their completion. You don't need
thread support in your libc or perl, and the threads created by this
module will not be visible to the pthreads library.


Linux does support POSIX AIO these days. You'd lose asynchronous open, close, stat, and unlink, but end up with much simpler POSIX-compliant code. It would probably shave off some thread overhead too. Thoughts?
(Reply) (Parent) (Thread)
[User Picture]From: brad
2005-04-18 12:33 am (UTC)
I flat-out need async open/close/stat/unlink, though. Perlbal used to do all 4 of those sync and it just sucked. Moved to Linux::AIO and it started screaming. We were just stalling the eventloop way too easily before.
(Reply) (Parent) (Thread)
[User Picture]From: aaronlehmann
2005-04-18 12:56 am (UTC)
Out of curiosity, why do you need Linux::AIO to be portable? Are you planning to use it on, say, HPPA?
(Reply) (Parent) (Thread)
[User Picture]From: brad
2005-04-18 01:00 am (UTC)
So it can be included in Debian.
(Reply) (Parent) (Thread)
[User Picture]From: aaronlehmann
2005-04-18 01:19 am (UTC)
Ah, I had a feeling that's what this was all about. I just asked the release manager and he's not aware of any reason why a perl module in Debian would need to run on all the architectures. If the Architecture line is change to just specify the architectures where it works, that should suffice.
(Reply) (Parent) (Thread)
[User Picture]From: taral
2005-04-18 01:14 am (UTC)
Ew, ew, ew. Why aren't they using pthreads?
(Reply) (Thread)