Re: missing m4/version.m4 in branch engine-pu
thanks. I found it 2013/1/7 dormando dorma...@rydia.net Hi. I clone the code from github. After checkout engine-pu, I run autoreconf -f --install to create configure, and fail. aclocal tell me, no m4/version.m4. I copy version.sh from branch master, then everything is ok. I wonder why there isn't version.sh. The autogen stuff got moved to a sub directory... I forget which, go find it! -- -- liubo
Re: about thread's stat
I means, if there are some work to improve memcache, I will try to code it. memcache has been widely used，it's perfect software. I just want to learn from it , and contribute it if I can. 2013/1/4 liubo lb.falc...@gmail.com Now,reading the code. But not just read,I want to try make some code to improve it. 2013/1/4 dormando dorma...@rydia.net Yeah. Removing contended locks gives more speedup. But noting the performance numbers from 1.4.15, going even faster than that is almost useless. It's very hard to get your network to perform up to those levels. Though there's still room for improvement. Are you just reading the code academically, or do you have a problem you're trying to solve? On Fri, 4 Jan 2013, liubo wrote: remove global mutex will get more speed up，right？ 2013/1/4 liubo lb.falc...@gmail.com For example,slabs_lock?? some global mutex. 2013/1/4 dormando dorma...@rydia.net Hello. I found all stat is protected by thread's mutex. All event is running in the signal thread context. Why need the protect,for sum?? or for command STAT?? thanks It's for when the summation happens, you can get consistent reads. NOTES, SINCE I HEAR THIS A LOT: *uncontested* mutexes aren't free, but are very nearly free. *contested* mutexes slow things down a lot. Since those thread locks are only ever called in the brief times in which you actually run stats commands, they have a very very small amount of overhead. When I was doing the lock scaling patches for 1.4.10-1.4.15 I did test this out: https://github.com/dormando/memcached/commit/56ad41e1a19a7fc99da51bdca4fdcb524a300984 (a little further work would be required to make that change permanent). On 64bit systems you can do 64bit-aligned 8 byte memory reads atomically, so as long as the stats structure is all 64bit items, is 64bit aligned, and the external reader is ... just a reader, you can get pretty accurate readings. on 32bit you need the lock. So I thought I'd try removing the locks on my 64bit system and test it. There was *ALMOST NO* change in performance. I can't stress this enough. Everyone focuses on these locks but if you bust out a God Damned Ruler they don't even use crap for cycles. The other work I did ended up having a much higher effect when tested, and I merged those branches instead. I think it was between 1-5% change in speed. By comparison making the lock shorter in the item_alloc code was a 15-30% bump. It'll be nice to remove the uncontested locks and save some CPU, but it was a much lower priority than other work. have fun, -Dormando -- -- liubo -- -- liubo -- -- liubo -- -- liubo
Re: about thread's stat
Now,reading the code. But not just read,I want to try make some code to improve it. 2013/1/4 dormando dorma...@rydia.net Yeah. Removing contended locks gives more speedup. But noting the performance numbers from 1.4.15, going even faster than that is almost useless. It's very hard to get your network to perform up to those levels. Though there's still room for improvement. Are you just reading the code academically, or do you have a problem you're trying to solve? On Fri, 4 Jan 2013, liubo wrote: remove global mutex will get more speed up，right？ 2013/1/4 liubo lb.falc...@gmail.com For example,slabs_lock?? some global mutex. 2013/1/4 dormando dorma...@rydia.net Hello. I found all stat is protected by thread's mutex. All event is running in the signal thread context. Why need the protect,for sum?? or for command STAT?? thanks It's for when the summation happens, you can get consistent reads. NOTES, SINCE I HEAR THIS A LOT: *uncontested* mutexes aren't free, but are very nearly free. *contested* mutexes slow things down a lot. Since those thread locks are only ever called in the brief times in which you actually run stats commands, they have a very very small amount of overhead. When I was doing the lock scaling patches for 1.4.10-1.4.15 I did test this out: https://github.com/dormando/memcached/commit/56ad41e1a19a7fc99da51bdca4fdcb524a300984 (a little further work would be required to make that change permanent). On 64bit systems you can do 64bit-aligned 8 byte memory reads atomically, so as long as the stats structure is all 64bit items, is 64bit aligned, and the external reader is ... just a reader, you can get pretty accurate readings. on 32bit you need the lock. So I thought I'd try removing the locks on my 64bit system and test it. There was *ALMOST NO* change in performance. I can't stress this enough. Everyone focuses on these locks but if you bust out a God Damned Ruler they don't even use crap for cycles. The other work I did ended up having a much higher effect when tested, and I merged those branches instead. I think it was between 1-5% change in speed. By comparison making the lock shorter in the item_alloc code was a 15-30% bump. It'll be nice to remove the uncontested locks and save some CPU, but it was a much lower priority than other work. have fun, -Dormando -- -- liubo -- -- liubo -- -- liubo
Re: Issue 303 in memcached: where is the current code? here or github
Now,I think, it's clear. Just 1 addition and 1 deletion. 2012/12/31 dormando dorma...@rydia.net For some reason your patch on github has a 100% diff, so I can't actually see your change. Did your editor change the line endings or something? On Sun, 30 Dec 2012, Bo Liu wrote: I know what happen. Because of my aclocal and automake has multi version. But, in autogen.sh, automake's version is 1.12, but aclocal is not 1.12. So, I think some data is mismatching. When I add aclocal-1.12, no error happens. I don't know why. BTW,It's a right way to add version in autogen.sh? 在 2012年12月31日星期一UTC+8下午12时38分56秒，Bo Liu写道： run autogen.sh to create configure ?? 在 2012年12月31日星期一UTC+8上午11时28分16秒，Bo Liu写道： os is centos 5.4 在 2012年12月31日星期一UTC+8上午11时21分12秒，Bo Liu写道： thank you for you reply. here is my operation: [liubo@linux64 github]$ git clone git:// github.com/memcached/memcached.git memcached/ Cloning into memcached... remote: Counting objects: 7780, done. remote: Compressing objects: 100% (2922/2922), done. remote: Total 7780 (delta 5523), reused 6514 (delta 4555) Receiving objects: 100% (7780/7780), 5.30 MiB | 10 KiB/s, done. Resolving deltas: 100% (5523/5523), done. [liubo@linux64 github]$ cd memcached [liubo@linux64 memcached]$ ./autogen.sh aclocal... autoheader... automake... configure.ac:7: error: version mismatch. This is Automake 1.12, configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE configure.ac:7: comes from Automake 1.7.9. You should recreate configure.ac:7: aclocal.m4 with aclocal and run automake again. configure.ac:5: installing './config.guess' configure.ac:5: installing './config.sub' configure.ac:7: installing './install-sh' Makefile.am: installing './depcomp' configure.ac:7: error: version mismatch. This is Automake 1.12, configure.ac:7: but the definition used by this AM_INIT_AUTOMAKE configure.ac:7: comes from Automake 1.7.9. You should recreate configure.ac:7: aclocal.m4 with aclocal and run automake again. Makefile.am: installing './INSTALL' Makefile.am: error: required file './README' not found doc/Makefile.am:12: warning: '%'-style pattern rules are a GNU make extension doc/Makefile.am:15: warning: '%'-style pattern rules are a GNU make extension doc/Makefile.am:18: warning: '%'-style pattern rules are a GNU make extension [liubo@linux64 memcached]$ ls aclocal.m4 autogen.sh cache.h config.subdaemon.c Doxyfile hash.h items.h memcached.c memcached.spec.in sasl_defs.c slabs.c stats.htimedrun.c version.m4 assoc.c autom4te.cache ChangeLog configure.ac depcomp globals.c INSTALL LICENSE memcached_dtrace.d NEWS sasl_defs.h slabs.h t trace.h version.pl assoc.h BUILD config.guess CONTRIBUTING devtools HACKINGinstall-sh m4 memcached.h protocol_binary.h scripts solaris_priv.c testapp.c util.c version.sh AUTHORS cache.c config.h.in COPYING doc hash.c items.c Makefile.am memcached.spec README.md sizes.c stats.c thread.c util.h [liubo@linux64 memcached]$ My automake is to old ?? 在 2012年12月31日星期一UTC+8上午11时03分07秒，memc...@googlecode.com写道： Updates: Status: Invalid Comment #1 on issue 303 by dorma...@rydia.net: where is the current code? here or github http://code.google.com/p/memcached/issues/detail?id=303 github. The master branch should work fine? Why is this a bug report? if you're having trouble finding/building it, please use the mailing list to ask for help. Please include the full output from autogen.sh, at the very least. -- -- liubo
