lvs sync, unusual load (sorry this isn't in the old thread)
Roberto Nibali
ratz at drugphish.ch
Thu Mar 1 10:17:14 GMT 2007
> 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 */
There's no ssleep anymore in ip_vs_sync.c since this commit:
commit 89eaeb09ba01632511f69ce8e14c8d2abd2dbe9e
Author: Simon Horman <horms at verge.net.au>
Date: Sun Dec 10 22:35:24 2006 -0800
[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.
This is the second edition of this patch, which replaces ssleep()
in the main loop for both the master and backup threads, as well
as some thread synchronisation code. The latter is just for thorougness
as it shouldn't be causing any problems.
Signed-Off-By: Simon Horman <horms at verge.net.au>
Signed-off-by: David S. Miller <davem at davemloft.net>
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
Search lvs-users Archives
More information about the lvs-users
mailing list