- 1. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Tue, 6 Aug 2013 09:45:24 +0300 (EEST)
- Hello, Reading your reply I see that the key issue you are missing here is that the type of loh/doh matters, it should match the type of atomic_read (and its signedness). As atomic_t is int we prefer
- /html/lvs-devel/2013-08/msg00004.html (12,822 bytes)
- 2. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Simon Kirby <sim@xxxxxxxxxx>
- Date: Mon, 5 Aug 2013 19:41:50 -0700
- Hello! Did you mean here "(__s64) loh * (__s32) atomic_read(&dest->sweight)"? If not, the results for me on GCC 4.7.2 were what I posted at http://0x.ca/sim/ref/3.9-ipvs/. I found that u64*u32 was fa
- /html/lvs-devel/2013-08/msg00001.html (13,922 bytes)
- 3. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Mon, 5 Aug 2013 09:10:24 +0300 (EEST)
- Hello, Simon, any progress on this change? I can continue and finish it if you prefer so? Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-deve
- /html/lvs-devel/2013-08/msg00000.html (11,393 bytes)
- 4. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Fri, 24 May 2013 11:11:35 +0300 (EEST)
- Hello, I now see why your patch shows difference compared to my tests month ago. This change is the culprit: - int loh, doh; + unsigned int loh, doh; It effectively changes the operation from: (__u64
- /html/lvs-devel/2013-05/msg00069.html (12,940 bytes)
- 5. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Simon Kirby <sim@xxxxxxxxxx>
- Date: Thu, 23 May 2013 17:43:18 -0700
- It's always 4 bytes, but gcc does more stuff with u64 * s32 than it does with u64 * s32. atomic_t seems to be int, so s32 on either arch. :) For the u64 * u32 case, it is using the single operand for
- /html/lvs-devel/2013-05/msg00067.html (12,169 bytes)
- 6. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Thu, 23 May 2013 23:44:22 +0300 (EEST)
- Hello, Hm, only sizeof(long int) should differ between 32-bit and 64-bit platforms, atomic_t is always int, int is returned from atomic_read and int is always 4 bytes. Last time I also checked the as
- /html/lvs-devel/2013-05/msg00066.html (10,666 bytes)
- 7. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Simon Kirby <sim@xxxxxxxxxx>
- Date: Thu, 23 May 2013 09:58:36 -0700
- Hello! Yes, see: http://0x.ca/sim/ref/3.9-ipvs/ The case of just (__u64) on i386 looks not very good, but making the weight also unsigned (__u32) seems to improve things. I set up a test harness (ipv
- /html/lvs-devel/2013-05/msg00065.html (11,581 bytes)
- 8. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Wed, 22 May 2013 09:18:03 +0300 (EEST)
- Hello, Any progress on this problem? Regards -- Julian Anastasov <ja@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxx
- /html/lvs-devel/2013-05/msg00052.html (11,918 bytes)
- 9. Re: activeconns * weight overflowing 32-bit int (score: 1)
- Author: Julian Anastasov <ja@xxxxxx>
- Date: Sat, 13 Apr 2013 18:10:18 +0300 (EEST)
- Hello, There is no big difference between 50 and 256. May be we can avoid 64-bit multiply with a - if (loh * atomic_read(&dest->weight) > - doh * atomic_read(&least->weight)) { + if ((__u64) loh * at
- /html/lvs-devel/2013-04/msg00006.html (11,097 bytes)
- 10. activeconns * weight overflowing 32-bit int (score: 1)
- Author: Simon Kirby <sim@xxxxxxxxxx>
- Date: Fri, 12 Apr 2013 23:43:55 -0700
- Hello! We use lblc in some environments to try to maintain some cache locality. We recently had some problems upgrading beyond 2.6.38 in one environment. The cluster kept overloading real servers and
- /html/lvs-devel/2013-04/msg00005.html (9,674 bytes)
This search system is powered by
Namazu