On Dec 8 02:51, Mark Geisert wrote: > (Maybe cygwin-developers is a better list for this? It's pretty obscure.)
Yes, cygwin-developers is fine since it's gory implementation details. > Here are some mutex lock stats I've been talking about providing. These are > from the OP's original testcase 'git repack -a -f' running over a clone of > the newlib-cygwin source tree. Run on a 2-core, 4-HT machine under Windows > 7 x64. I'm running a slightly modified cygwin1.dll that has 3 one-line mods > to thread.cc. Which I'd like to see a patch of, just to know what you mean. > I'm considering adding the tools that produced these displays to the > cygutils package. I'm unsure if the cygwin1.dll mods I've made locally > should be shipped generally; I don't know how much extra CPU they use, if > any. Well, let's have a look. This is open source after all :) > caller 0x018014CC77, count 1, L, /oss/src/winsup/cygwin/thread.cc:475 > caller 0x018014CD00, count 1, U, /oss/src/winsup/cygwin/thread.cc:496 > caller 0x018014CDAF, count 432, L, /oss/src/winsup/cygwin/thread.cc:971 > caller 0x018014CDE6, count 432, U, /oss/src/winsup/cygwin/thread.cc:982 > caller 0x018014D07E, count 1, L, /oss/src/winsup/cygwin/thread.cc:1946 > caller 0x018014D090, count 1, U, /oss/src/winsup/cygwin/thread.cc:1951 > caller 0x018014D7E6, count 1, L, /oss/src/winsup/cygwin/thread.cc:525 > caller 0x018014D7FF, count 1, U, /oss/src/winsup/cygwin/thread.cc:533 > caller 0x018014EDD7, count 1, U, /oss/src/winsup/cygwin/thread.cc:2400 > caller 0x018014EE97, count 1, L, /oss/src/winsup/cygwin/thread.cc:2389 This is interesting. I'm not sure if anything in the rest of the output shows how much is wasted on the above two calls, though. thread.cc:971 and thread.cc:982 are pthread_setcancelstate, and it's called pretty often as part of stdio functions. Every stdio function which has to lock the FILE structure also calls pthread_setcancelstate to disable and reenable cancellation before and after locking. That's almost any stdio function. This may be one of the problems which lower performance, but there's no easy or quick way around that, AFAICS. There's also the fact that, even for tools using __fsetlocking to disable stdio locking, pthread_setcancelstate will still be called unconditionally. The question here is, if that's wrong and pthread_setcancelstate should be skipped if the application sets FSETLOCKING_BYCALLER. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpx1uvuH8_bH.pgp
Description: PGP signature
