[Xorp-hackers] Selector overhead; SelectorList bugs

Ben Greear greearb at candelatech.com
Tue Dec 1 08:27:21 PST 2009


On 12/01/2009 01:32 AM, Bruce Simpson wrote:
> Bruce Simpson wrote:
>> Just thinking aloud here about the implications of the performance
>> profiling experiments I've been doing.
>>
>> There's room for improvement here. If someone stepped up to rewriting
>> the Selector to use poll(), that would give us more flexibility with
>> I/O ordering, but remain portable to the UNIX platforms we support.
>
> I had a brief exchange in private message with an old friend of mine.
> She mentioned that she'd been hacking with OpenSolaris' port(3C). Looks
> to me like Sun went ahead and 'did' I/O completion ports, NT style.
>
> So it seems we've got 4 nifty alternatives, none of them particularly
> portable: port, Apple's Grand Central Dispatch, kqueue, and epoll.
>
> With epoll, lowest fds get highest dispatch priority. With GCD, you need
> to explicitly push objects into priority queues; looks like it's coming
> to Linux soon. It's not immediately clear to me how to do relative I/O
> priority with port(3C). kqueue is BSD only.
>
> Sounds like a job for good old poll().

I don't see how priority matters in poll() anyway.  It will return all fds that
can have action taken on them..then user-space can process those fds however
it wants.

One simple optimization might be to check return value of poll/select to
see how many items have bits set..then you at least know when you can stop
the loop.

But, all that said, I think optimizing that is not high priority...we should
fix bugs (like that OSPF thing recently reported) at a higher priority.

Thanks,
Ben



More information about the Xorp-hackers mailing list