About this list Date view Thread view Subject view Author view Attachment view

From: Sam Vilain (sam_at_vilain.net)
Date: Mon 05 Sep 2005 - 23:42:28 BST

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

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 :).


Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Mon 05 Sep 2005 - 23:40:27 BST by hypermail 2.1.3