> > * We might be able to tweak io-threads (which already runs on the > > bricks and already has a global queue) to schedule requests in a > > fairer way across clients. Right now it executes them in the > > same order that they were read from the network. > > This sounds to be an easier fix. We can make io-threads to factor in another > input i.e., the client through which request came in (essentially > frame->root->client) before scheduling. That should make the problem > bearable at-least if not crippling. As to what algorithm to use, I think we > can consider leaky bucket of bit-rot implementation or dmclock. I've not > really thought deeper about the algorithm part. If the approach sounds ok, > we can discuss more about algos. I've created a patch to address the most basic part of this, in the simplest way I could think of. http://review.gluster.org/#/c/14904/ It's still running through basic tests, so I don't even know if it's really correct yet, but it should give an idea of the conceptual direction. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
