On Mon, 2005-09-05 at 17:15 +0200, Herbert Poetzl wrote: > On Mon, Sep 05, 2005 at 08:53:55PM +1200, Sam Vilain wrote: > > The attached patch fixes a bug when you use "vsched" on a running > > vserver on amd64, in which the high 32 bits of various scheduling > > parameters could be filled with garbage, causing tokens to be allocated > > at vastly incorrect rates. > how and why? any details? sounds like a > gcc bug to me (at first glance, maybe I'm wrong)
Yes, there is a lot of guesswork in the diagnosis. Here's what I was seeing. If I increased the size of the token bucket via vsched to, say, 50000, and set its size to zero, then the bucket would still be instantly filled, even with a 1:100 fill rate. At various times it would could up or down for a short while, and then reset to full again, but always less than 100 from the maximum (with a 1:100 fill rate). This behaviour is consistent with what you'd expect if values were wrapping around because of unwanted bits in the upper half of the word when calculations happened, that were later truncated to 32 bits again. That was an early guess, and my change stopped the problem from re-appearing. I agree with you that that prognosis would make this a compiler bug (I'm on gcc 3.3.5), but I think it is a good idea to avoid such bugs by avoiding mixed long / int calculations where possible. > so I consider this a bandaid at most ... > will look into the code soon ... Sure. If you have any better idea about how to really get to the bottom of this, let me know how I can help. All the ways I can see are in a distant field of pain :). Sam. _______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
