On Dec 8 16:34, Corinna Vinschen wrote: > 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.
For a start, I simply removed the mutex lock/unlock in calls to pthread_setcancelstate and pthread_setcanceltype. These locks are completely unnecessary. These functions are only called for the current thread anyway. I'm just creating a developer snapshot which I'll upload to https://cygwin.com/snapshots/ in half an hour at the latest. Please have a look if your testcase behaves better now. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp4umntGRtjF.pgp
Description: PGP signature
