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
