Re: FOP ratelimit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Something ceph is working on "dmclock"

http://tracker.ceph.com/projects/ceph/wiki/Rados_qos

might be we can talk to them ?

~Joe


----- Original Message -----
From: "Jeff Darcy" <jdarcy@xxxxxxxxxx>
To: "Joseph Fernandes" <josferna@xxxxxxxxxx>
Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>, "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, "Venky Shankar" <vshankar@xxxxxxxxxx>, "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx>, "Shyamsundar Ranganathan" <srangana@xxxxxxxxxx>
Sent: Thursday, September 10, 2015 6:57:51 PM
Subject: Re:  FOP ratelimit?

> Have we given thought about other IO scheduling algorithms like mclock
> algorithm [1], used by vmware for their QOS solution.
> Plus another point to keep in mind here is the distributed nature of the
> solution. Its easier to think of a brick
> controlling the throughput for a client or a tenant. But how would this work
> in collaboration and scale with all the
> bricks together, what I am talking about is Distributed QOS.

At the packet level, this is a core problem that SDN has to solve.  When
we're running in an SDN environment, we should just hand off responsibility
for QoS to them.  Otherwise, we should probably steal their algorithms.  ;)
I believe there are some experts elsewhere at Red Hat whose brains we can
and should pick.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux