[sheepdog] [RFC PATCH] sdnet: threading tx/rx process

[HaiTing Yao]

On Mon, Jul 16, 2012 at 4:51 PM, Liu Yuan <namei.unix at gmail.com> wrote:
> On 07/16/2012 04:38 PM, Christoph Hellwig wrote:
>>> Well, so in your proposal, per connection we have 2
>>> > threads(rx/tx),right?
>> In the original one, yes.  The other option is to use a fixed number
>> of RX/TX threads and just hash the connections onto them.  Given that
>> the RX/TX threads only do non-blocking I/O in theory one per CPU should
>> actually be enough.
>>
>
> The connection management adds the complexity. And the benefit we gain
> from it might not be worthy of this complexity.

I think we can use a fixed number of RX/TX threads. We can also make
the threads can be spawned/removed like pdflush threads. I will try to
implement this. Let's make things simple. The threads do not have
binding relation to connections, but one rx threds pool and one tx
threads pool.

Thanks
Wujue

>
>>> > Still too many connections. Yes, we can avoid
>>> > context switches, but I suspect that context switches doesn't count much
>>> > because we'll do a disk IO in a perspective of one request. To
>>> > conclusion, I think we can afford 2 more context switches. (We can
>>> > optimize this by redesign thread implementation later)
>> My other problem with excessive workqueue use is that it makes debugging
>> code flows pretty hard.
>>
>
> Why is harder than before?
>
> For now, the real problem is that dynamic can't work with tracer code. I
> think my proposal is simplest one to overlap requests, also using single
> epoll() to manage all the fds looks neat.
>
> We can still avoid most of context switches if we implement a dynamic
> grow/shrink threads pool which looks to be a fixed threads pool from
> outside.
>
> Thanks,
> Yuan
> --
> sheepdog mailing list
> sheepdog at lists.wpkg.org
> http://lists.wpkg.org/mailman/listinfo/sheepdog