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 |