User: Password:
Subscribe / Log in / New account

Performance aspects

Performance aspects

Posted Aug 3, 2006 15:44 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: Performance aspects by pphaneuf
Parent article: Toward a kernel events interface

The thing is, there already are a whole lot of features to deal with this, many of which are not used as often as they should.

For example, the "minimum amount of data" option exists already for ages for socket (SO_LOWWAT or some such). There's POSIX realtime signals which can be queued and even start a new thread at a particular callback when the signal arrives.

All these things are aimed at the really high end though, 99% of programs don't need to worry about this much...

(Log in to post comments)

Performance aspects

Posted Aug 3, 2006 16:20 UTC (Thu) by pphaneuf (subscriber, #23480) [Link]

According to socket(7), there's SO_RCVLOWAT and SO_SNDLOWAT, but they are not changeable on Linux, being always set at 1 (i.e. nothing special).

Waiting for POSIX signals is a system call too (in fact, getting them too). I don't think there's anything about starting new threads like that on Linux.

Performance-wise, other than holding off readiness events until a certain amount is ready (which appears already has an unimplemented API), I'm fairly happy. Back when I used epoll in edge-triggered mode, I would have liked a way to batch calls to epoll_ctl(), when I re-armed my events, but now I just let the kernel-side level-triggered mode do the work.

Performance aspects

Posted Aug 3, 2006 16:37 UTC (Thu) by cventers (guest, #31465) [Link]

Realtime signals and new-thread callbacks were mentioned in Ulrich's OLS
paper. He went on to show how truly inoptimal they were.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds