On Mon, 7 Jun 2010 05:43:00 am Michael S. Tsirkin wrote: > On Fri, Jun 04, 2010 at 10:28:56AM +0930, Rusty Russell wrote: > > This patch is a subset of an already upstream patch, but this portion > > is useful in earlier releases. > > > > Please consider for the 2.6.32 and 2.6.33 stable trees. > > > > If the add_buf operation fails, indicate failure to the caller. > > > > Signed-off-by: Bruce Rogers <brogers@xxxxxxxxxx> > > Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx> > > Actually this code looks strange: > Note that add_buf inicates out of memory > condition with a positive return value, and ring full > (which is not an error!) with -ENOSPC. > > So it seems that this patch (and upstream code) will fill > the ring and then end up setting oom = true and rescheduling the work > forever. And I suspect I actually saw this at some point > on one of my systems: observed BW would drop > with high CPU usage until reboot. > Can't reproduce it now anymore .. I thought that at first too, but it's subtler than that. When the ring is exactly filled, err = 0. With mergeable bufs and small bufs that's the. With big buffers, it's probably not, and the code will indeed respond as if always out of memory, always trying to refill. Our current code has the same error. Probably a combination of noone using big buffers, and noone noticing one timer every 1/2 second. Want to fix that properly? And comment it? :) Thanks, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
