Latency/efficiency: on worker wakeup an idle server can be picked from
the list and context-switched into synchronously, on the same CPU.
Using FDs and select/poll/epoll will add extra layers of abstractions;
synchronous context-switches (not yet fully implemented in UMCG) will
most likely be impossible. This patchset seems much more efficient and
lightweight than whatever can be built on top of FDs.
I can believe that.
Are you planning to support separate scheduling instances within a single user
space? That is having multiple sets of server threads and workers can only run
within a specific set.
I believe the problem with the idle_servers_ptr as specified is that it is not
possible to reclaim used nodes safely. I don't see any indication of which
nodes the kernel can concurrently access and on which some memory reclamation
scheme could be based.
What is the benefit of having users maintain themselves a list of idle servers
rather than each servers marking themselves as 'out of work' and having the
kernel maintain the list?