Re: epoll scheduler
Alexey Andriyanov <[email protected]>
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Message-ID | <[email protected]> |
Yes, that synchronous work is pretty fun! It would be interesting for me to compare our implementations. I used an rbtree too :) This is mine: https://github.com/andriyanov/keepalived/commits/epoll NetSNMP support was a most painful part ) 18.08.2015 04:14, Alexandre Cassen пишет: > Hi Alexey, > > I have already ported scheduler to use epoll too :D we are aligned ! :D that is excellent... I can share with you offline. I am using this extended version of scheduler in my job. I added a bunch of extensions in order to get ride of current limitations. Specially making extensive use of rbtree for timer and/or timeouted operations. > > I didn’t merge this part yet because it way of working is not the same as select, with epoll we have to explicitly DEL fd from fdset while select automatically remove fd upon event. > > I can share that code with you offline for investigations. Using epoll is a natural evolution (select is so 90’s). Will send you the code for investigation. > > regs, > Alexandre > > > >> On 17 Aug 2015, at 21:42, Alexey Andriyanov <[email protected]> wrote: >> >> Hi, Alexandre! >> >> Recently I was struggling from exceeding of the opened filehandles limit (1024) in my keepalived. >> Increasing the limit did not help at all: keepalived's scheduler is using select(2) that is limited to 1k descriptors by design. >> >> I did not investigate of the root cause accurately and began to work on using epoll(7) in the scheduler. >> >> Now I've got a working epoll implementation. It is more effective than the current one, because it does not use list traversal to search for a thread struct. I have profiled the heavy-scheduled config with 2k local checkers and proved that scheduler is the most cpu-intensive part in this scenario and that the new scheduler is more than twice faster than the current one. >> >> However, afterwards it turned out that the real problem was in high CPU usage in libssl and it gone away by updating this lib. The problem was not in the scheduler and I don't need the epoll implementation any more. >> >> If you think it might be useful for some users, I'll post it for review or make a pull request. >> >> -- >> Best regards, >> Alexey > -- Best regards, Alexey ------------------------------------------------------------------------------ _______________________________________________ Keepalived-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/keepalived-devel