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

[Ryan Cruse]

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 at xxxxxxxxxxxxx>
>> Signed-Off-By: Simon Horman <horms at 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 at LinuxVirtualServer.org
> Send requests to lvs-users-request at LinuxVirtualServer.org
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>