Re: Cygwin multithreading performance

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

[-- Attachment #1: Type: text/plain, Size: 3257 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]