On 01/25/16 18:24, Ravishankar N wrote:
On 01/26/2016 01:22 AM, Shreyas Siravara wrote:
Just out of curiosity, what benefits do we think this throttling
xlator would provide over the "enable-least-priority" option (where
we put all the fops from SHD, etc into a least pri queue)?
For one, it could provide more granularity on the amount of throttling
you want to do, for specific fops, from specific clients. If the only
I/O going through the bricks was from the SHD, they would all be
least-priority but yet consume an unfair % of the CPU. We could tweak
`performance.least-rate-limit` to throttle but it would be a global
option.
Right, because as it is now, when shd is the only client, it queues up
so much iops that higher prioritiy ops are still getting delayed.
On Jan 25, 2016, at 12:29 AM, Venky Shankar <vshankar@xxxxxxxxxx>
wrote:
On Mon, Jan 25, 2016 at 01:08:38PM +0530, Ravishankar N wrote:
On 01/25/2016 12:56 PM, Venky Shankar wrote:
Also, it would be beneficial to have the core TBF implementation
as part of
libglusterfs so as to be consumable by the server side xlator
component to
throttle dispatched FOPs and for daemons to throttle anything
that's outside
"brick" boundary (such as cpu, etc..).
That makes sense. We were initially thinking to overload
posix_rchecksum()
to do the SHA256 sums for the signer.
That does have advantages by avoiding network rountrips by computing
SHA* locally.
TBF could still implement ->rchecksum and throttle that (on behalf
of clients,
residing on the server - internal daemons). Placing the core
implementation as
part of libglusterfs would still provide the flexibility.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.gluster.org_mailman_listinfo_gluster-2Ddevel&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=N7LE2BKIHDDBvkYkakYthA&m=9W9xtRg0TIEUvFL-8HpUCux8psoWKkUbEFiwqykRwH4&s=OVF0dZRXt8GFcIxsHlkbNjH-bjD9097q5hjVVHgOFkQ&e=
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
