Mail Archives: cygwin/2015/12/08/10:35:14
--KIzF6Cje4W/osXrF
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 Windo=
ws
> 7 x64. I'm running a slightly modified cygwin1.dll that has 3 one-line mo=
ds
> 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
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--KIzF6Cje4W/osXrF
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWZviOAAoJEPU2Bp2uRE+gFlEP/0DDHBD3/+SkKj2vRk7eO5VK
+UmzlaejHzDn9CA4nzqH+lqSgWXyHkSRfSb07S2rvh+FTpVOeDvjXQ0dQdbCn3v2
hBwPqkBD+XG8t4wLlIdaZ4Dh16wKlDTIGFNXut02v/VOmSr+OJ4wRSY8xQDZFQ08
KzbpFifjIFcc/MbadfAlvIfN8q1XagccOpSdmoEPPEzyaCFbN1gQVOP61EOaNNVT
Tao385JL/WSxeJGUwEVZplwFNxz6/OH7qMr6aV4PV7ZxjZ2uWDg/WkhXOaW4JwoR
wexBYLT2N8jXhCpPD+NFSKvRgp9uTPOblC027UQMSEQM2ykd1+O0GrKuV+Ih1dMR
nV46gncqAQUfZkSmfaPD4+athewguZxdqe8RlrZnuIKgyKKi130Ur2WvxeXe4Ujn
G/FlBgVjyUQTHsDvThRwPI+rfv307tQ8S9ghmdo0E+hICpDoUyXmryLpDNZpM3FM
oXqTX0t7pPu5u51FAMugrcBUXJl01MJcbxFeEFYhQEpxUSCWjpvQ874EgiWSs/eX
ReSMbS+vP20+y35XXjy2chbyXpFNvLPdea+gu4CrrtYz9qC6YqKNvz/iJSBwqYoP
hYMFMZuMhUbyYkgIN8TawKGLFjhbgCb85cUTz0HyMoTBXYW0hCpNuhas1w4qU3pT
UiWr/CC4Byv4aLVdsC/f
=g6Gu
-----END PGP SIGNATURE-----
--KIzF6Cje4W/osXrF--
- Raw text -