Re: Cygwin multithreading performance

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

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

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

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