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
