> 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?
