On Tue, Sep 20, 2011 at 8:34 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > On Mon, Sep 19, 2011 at 05:55:41PM +0800, Zhi Yong Wu wrote: >> On Wed, Sep 14, 2011 at 6:50 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: >> > On Tue, Sep 13, 2011 at 11:09:46AM +0800, Zhi Yong Wu wrote: >> >> On Fri, Sep 9, 2011 at 10:44 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: >> >> > On Thu, Sep 08, 2011 at 06:11:07PM +0800, Zhi Yong Wu wrote: >> >> >> Note: >> >> >> 1.) When bps/iops limits are specified to a small value such as 511 bytes/s, this VM will hang up. We are considering how to handle this senario. >> >> > >> >> > You can increase the length of the slice, if the request is larger than >> >> > slice_time * bps_limit. >> >> Yeah, but it is a challenge for how to increase it. Do you have some nice idea? >> > >> > If the queue is empty, and the request being processed does not fit the >> > queue, increase the slice so that the request fits. >> Sorry for late reply. actually, do you think that this scenario is >> meaningful for the user? >> Since we implement this, if the user limits the bps below 512 >> bytes/second, the VM can also not run every task. >> Can you let us know why we need to make such effort? > > It would be good to handle request larger than the slice. > > It is not strictly necessary, but in case its not handled, a minimum > should be in place, to reflect maximum request size known. Being able to > specify something which crashes is not acceptable. HI, Marcelo, any comments? I have post the implementation based on your suggestions > > -- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
