View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004126||unreal||ircd||public||2012-10-05 05:03||2012-11-24 20:42|
|Fixed in Version||3.4-alpha1|
|Summary||0004126: [patch] new i/o recordkeeping code / evented i/o|
Attached is a patch implementing a new I/O recordkeeping system. This will allow us to move to evented I/O for 3.2.10.
The code is based on Mowgli's, with some ircd-specific features added.
|Tags||No tags attached.|
|3rd party modules|
unreal-fdtable.patch (14,876 bytes)
Last edited: 2012-10-05 05:57
Patch added. Please integrate into the tree, as my evented i/o stuff depends on this.
It has been tested on Linux and FreeBSD, Windows probably needs the new symbols added to wircd.def.
I will continue my work on my own mercurial tree, like before, I will push this to bitbucket.
Once the evented I/O patches are completed, I will add them to this bug. Thusly, do not close this bug once the recordkeeping patch is integrated!
As a sneak preview, http://rabbit.dereferenced.org/~nenolod/patches/unreal-fd_select-try1.patch contains an implementation of evented I/O for poll(2). Nothing is hooked up to it in this patch, but it should work.
Going to commit this and push it to my bitbucket tree momentarily. Then I will hook up c-ares to the new I/O loop and see how things go. If that goes well, then I will move over the plaintext client handler next, and rewrite the remote includes code to register itself with the new I/O loop (which will resolve the bug related to it crashing when used with poll(2) if there are too many clients).
Ok. Sorry for my lack of positive feedback, as I'm currently working on getting a test release for 3.2.10 :).
At a later stage I'll check things out and get back to you, but this may be months from now. If your goal is to make the I/O code actually readable and restructure things we can see if that can be put in 3.2.11, that would be nice. Right now that code is the worst readable part of UnrealIRCd (but it works...), but I read on IRC you already noticed... ;)
Here is an early cut at the new I/O code: http://rabbit.dereferenced.org/~nenolod/unreal-newio-without-fdtable.patch
What doesn't work 100% still:
- SAFELIST (might actually work, haven't tested it)
- remote includes (easy enough to fix)
- SSL (works sort of, but needs work to use the eventloop more efficiently)
Things that still need to be worked on:
- flush_connections() should go away, instead we should do edge-triggered writes like in charybdis (oops, i gave away one of our secrets on how we beat ratbox on i/o throughput ;))
- SSL / STARTTLS / etc eventloop integration
I think this is a 3.2.11 thing, as we're to a point where we just need to get things hammered out a little more.
Update on this... http://bitbucket.org/nenolod/unreal has a fully working ircd with the new i/o code. read_message() has been removed entirely.
I am going to start removing the remaining components of the fdlist code shortly, since it is no longer relevant. This leaves the question of what to do with the remaining heavy traffic mode code (which primarily determined what fdlists to check). Is it relevant anymore? My tree outperforms 3.2.10 even in heavy traffic mode by several magnitudes in terms of CPU to message throughput ratio... so I think HTM can just go away now with the fdlist code.
Once all of that is done, I am going to start looking at the spamfilter code. I think that there are some anticipatory optimizations we can make.
If you are right in 0004127 that there's a better solution than HTM, then as far as as HTM is concerned the fdlists can go. HTM is rarely triggered or actually used AFAICT.
The fdlist code is also used to prioritize (I think?). If this is no longer necessary because your code already deals with high traffic scenarios then the fdlists can go too.
Prioritizing reading is not too important, it's far more important to execute commands of clients at different priorities and with delay (the whole reason fake lag and things like dbuf exists).
If there's no reason to have fdlists around, please remove them, as they are only annoying to keep track of ;)
As for performance, it'd be nice if you could share any (reliable) test results with us :)
Sorry for not taking a better look at what you did so far, I realize you are doing a lot of work! I'll certainly get back to you at a later stage... I'd *like* to say tomorrow, but.. I'm pretty sure I won't be able to. Just want to say, keep up the good work.
Another update on this.
http://bitbucket.org/nenolod/unreal now has a tree with the entire 2.8 eventloop removed.
In regards for CPU usage, with the fully async tree, running 10000 chat bots across 30 channels (each sending a message every 50ms) and spamfilter disabled, CPU usage spikes between 3-5%. On HG tip, the usage is much higher than that... about 40% CPU on my server (which is a dual Opteron 4162-EE machine).
This also cleans up a lot of hairyness with the eventloop in general. There's a few optimizations which can be made, such as tracking whether or not writes would block and postponing them. There's also TCP_CORK which may be interesting to play with, but it's not portable.
In regards to integration, I think the best approach is just to pull my tree into HG tip after 3.2.10 is released and call it 3.3 at this point. The changes made here are worthy of going from 3.2 to 3.3 in my opinion.
This work of course does not do much to deal with badly composed spamfilters -- if you have a crap spamfilter the IRCd is still going to crap out until it is removed.
|Most of this is in 3.4.|
||File Added: unreal-fdtable.patch|
||Note Added: 0017139|
||Status||new => has patch|
||Note Edited: 0017139||View Revisions|
||Note Added: 0017140|
||Note Added: 0017141|
|2012-10-06 12:37||syzop||Note Added: 0017153|
||Note Added: 0017157|
||Note Added: 0017204|
|2012-10-27 14:07||syzop||Note Added: 0017208|
||Note Added: 0017224|
||Assigned To||=> nenolod|
||Status||has patch => assigned|
||Note Added: 0017242|
||Status||assigned => resolved|
||Fixed in Version||=> 3.4-alpha1|
||Resolution||open => fixed|