On Wed, Sep 21, 2011 at 11:14 AM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote: > On Tue, Sep 20, 2011 at 8:34 PM, Marcelo Tosatti <mtosa...@redhat.com> 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 <mtosa...@redhat.com> >>> 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 <mtosa...@redhat.com> >>> >> 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. > OK. Let me spend some time on trying your way. >> >> 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 > In fact, slice_time has been dynamic now, and adjusted in some range. Sorry, I made a mistake. Currently it is fixed. >> specify something which crashes is not acceptable. > Do you mean that one warning should be displayed if the specified > limit is smaller than the minimum capability? > >> >> > > > > -- > Regards, > > Zhi Yong Wu >
-- Regards, Zhi Yong Wu -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
