Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*activeconns\s+\*\s+weight\s+overflowing\s+32\-bit\s+int\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*activeconns\s+\*\s+weight\s+overflowing\s+32\-bit\s+int\s*$/: 10 ]

Total 10 documents matching your query.

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)

Current List: 1 - 10
Page: [1]