Re: (e)poll takeover

[Hans Henrik Happe]

On Wednesday 28 June 2006 20:04, Helge Bahmann wrote:
> > No, It's a latency thing in a distributed system. Basically thread B can 
both
> > be I/O-bound and CPU-bound. In the first case I want to avoid context
> > switching in order to minimize latency. In the later communication should
> > continue (servicing/forwarding requests), while thread B is doing
> > computation.
> 
> what about simply letting thread A/thread B race for event notification?
> with epoll you can do that (with plain poll obviously you cannot...), and
> you always get perfect latency (but you don't know which thread will
> eventually handle the event)

That will not work, because it's thread B that needs the data fetched by event 
handling. Perhaps I should be more precise:

The events are input events from a set of TCP socket. Thread A handles input 
from these sockets and updates state in a subsystem. Thread B calls into the 
subsystem to ask for input. If the required input is not available it has to 
request it from other nodes in the distributed system and wait for a reply.
In order to minimize the input path for thread B, it should do the input 
handling until the request are replied. 
 
> > > however all that still begs the question why you don't just let the
> > > threads swap roles
> >
> > The threads have very different call stacks. Also, this would not solve 
the
> > context switching issues.
> 
> this is really whacky, but... you *could* use setcontext and friends to
> switch to the other thread's call stack after returning from poll/epoll
> (instead of taking over event waiting in the other thread) -- basically
> you replace a kernel context switch with a user-space context switch

I'm seeing how this would work. Both threads would have to wait in a similar 
poll and wakeup behavior is undefined in this case.
 
> are you sure this kind of micro-optimization is really required in your
> case? If one thread is compute-bound, the scheduler will usually do the
> right thing

Well this is research and I'm trying to push TCP communication as far as 
possible in user-space without modifying the kernel. 

Thanks for all your input.

Hans
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html