Re: lvs sync, unusual load (sorry this isn't in the old thread)

[Ryan Cruse <ryan@xxxxxxxxxx>]

I probably should have looked a little further in the code before 
posting.  I assume the patch should have included the sync_backup_loop 
too.  Does anyone know if this is slated to get put out in upcoming 
kernels?  I haven't tested this yet but I assume it will work, since it 
is practically the same exact code that Horms fixed before. :)
Thanks,
-Ryan

--- ./ip_vs_sync.c      2007-02-27 14:23:58.000000000 -0500
+++ ./kernel-2.6.19/linux-2.6.19.x86_64/net/ipv4/ipvs/ip_vs_sync.c      
2007-02-27 15:27:42.000000000 -0500
@@ -657,7 +657,7 @@
               if (stop_master_sync)
                       break;

-               ssleep(1);
+               msleep_interruptible(1000);
       }

       /* clean up the sync_buff queue */
@@ -714,7 +714,7 @@
               if (stop_backup_sync)
                       break;

-               ssleep(1);
+               msleep_interruptible(1000);
       }

       /* release the sending multicast socket */


Ryan Cruse wrote:
> Hey Horms,
>
> I'm curious if Dean ever got back to you about this fix.  I am seeing 
> exactly what Dean saw.  I tried your fix with 2.6.19-1.2911 on Fedora 
> Core 6 and
> it didn't fix the issue.  After rebooting with the new kernel and 
> turning on the connection synchronization daemon the load returns to 
> 1.  The process is still in the 'D' state:  "D - Uninterruptible sleep 
> (usually IO)".  If there is anything else you'd like me to try out or 
> any more information about the issue let me know.
> Thanks,
> -Ryan
>
> > On Fri, Nov 10, 2006 at 03:15:05PM +0900, Horms wrote:
> > >/ On Fri, Nov 10, 2006 at 02:54:20PM +1100, Dean Manners wrote:/
> > >/ > Horms,/
> > >/ > /
> > >/ > ip_vs_sync.c: /
> > >/ > 885:        __set_current_state(TASK_UNINTERRUPTIBLE);/
> > >/ > 886:        add_wait_queue(&stop_sync_wait, &wait);/
> > >/ > 887:        set_stop_sync(state, 1);/
> > >/ > 888:        ip_vs_sync_state -= state;/
> > >/ > 889:        wake_up(&sync_wait);/
> > >/ > 890:        schedule();/
> > >/ > 891:        __set_current_state(TASK_RUNNING);/
> > >/ > 892:        remove_wait_queue(&stop_sync_wait, &wait);/
> > >/ > /
> > >/ > Seems to have changed? Theres no "schedule_timeout(HZ);" 
> > throughout./
> > >/ /
> > >/ Actually, that is the shutdown code./
> > >/ /
> > >/ The problem is almost certainly caused inside sync_master_loop()/
> > >/ somewhere. Though it is using ssleep(), but perhaps its 
> > schemantics have/
> > >/ changed somehow.. I can readily reproduce the problem here. I will 
> > see/
> > Is there any chance you could test out the change below to see if it
> > helps. It seems to work on my end.
> >
> > --
> > Horms
> >   H: http://www.vergenet.net/~horms/ <http://www.vergenet.net/%7Ehorms/>
> >   W: http://www.valinux.co.jp/en/
> >
> >
> > [IPVS] use msleep_interruptable() instead of ssleep() aka msleep()
> >
> > Dean Manners notices that when an IPVS synchonisation daemons are
> > started the system load slowly climbs up to 1. This seems to be related
> > to the call to ssleep(1) (aka msleep(1000) in the main loop. Replacing
> > this with a call to msleep_interruptable() seems to make the problem go
> > away. Though I'm not sure that it is correct.
> >
> > Cc: Dean Manners <deanm@xxxxxxxxxxxxx>
> > Signed-Off-By: Simon Horman <horms@xxxxxxxxxxxx>
> >
> > Index: linux-2.6/net/ipv4/ipvs/ip_vs_sync.c
> > ===================================================================
> > --- linux-2.6.orig/net/ipv4/ipvs/ip_vs_sync.c   2006-11-10 
> > 15:33:42.000000000 +0900
> > +++ linux-2.6/net/ipv4/ipvs/ip_vs_sync.c        2006-11-10 
> > 15:33:52.000000000 +0900
> > @@ -657,7 +657,7 @@
> >                 if (stop_master_sync)
> >                         break;
> >  
> > -               ssleep(1);
> > +               msleep_interruptible(1000);
> >         }
> >  
> >         /* clean up the sync_buff queue */
> >   
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users