Mail Archives: cygwin/2015/12/08/12:03:07
--yrj/dFKFPuw6o+aM
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 obscur=
e.)
>=20
> Yes, cygwin-developers is fine since it's gory implementation details.
>=20
> > Here are some mutex lock stats I've been talking about providing. Thes=
e 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 Win=
dows
> > 7 x64. I'm running a slightly modified cygwin1.dll that has 3 one-line =
mods
> > to thread.cc.
>=20
> Which I'd like to see a patch of, just to know what you mean.
>=20
> > 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.
>=20
> Well, let's have a look. This is open source after all :)
>=20
> > caller 0x018014CC77, count 1, L, /oss/src/winsup/cygwin/thread.c=
c:475
> > caller 0x018014CD00, count 1, U, /oss/src/winsup/cygwin/thread.c=
c:496
> > caller 0x018014CDAF, count 432, L, /oss/src/winsup/cygwin/thread.c=
c:971
> > caller 0x018014CDE6, count 432, U, /oss/src/winsup/cygwin/thread.c=
c:982
> > caller 0x018014D07E, count 1, L, /oss/src/winsup/cygwin/thread.c=
c:1946
> > caller 0x018014D090, count 1, U, /oss/src/winsup/cygwin/thread.c=
c:1951
> > caller 0x018014D7E6, count 1, L, /oss/src/winsup/cygwin/thread.c=
c:525
> > caller 0x018014D7FF, count 1, U, /oss/src/winsup/cygwin/thread.c=
c:533
> > caller 0x018014EDD7, count 1, U, /oss/src/winsup/cygwin/thread.c=
c:2400
> > caller 0x018014EE97, count 1, L, /oss/src/winsup/cygwin/thread.c=
c:2389
>=20
> 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.
>=20
> 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.
>=20
> This may be one of the problems which lower performance, but there's no
> easy or quick way around that, AFAICS.
>=20
> There's also the fact that, even for tools using __fsetlocking to disable
> stdio locking, pthread_setcancelstate will still be called unconditionall=
y.
> 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
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--yrj/dFKFPuw6o+aM
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWZw00AAoJEPU2Bp2uRE+geTgP/33pTd5J5SJuS1RYVyytpNMJ
E27u9SMPismr9UPhteTRbwFdbrXk/qPLnN7/d+61T8aoV977EfyxDfnYw9N0BTyM
QCsKdjPwHpLSqGX0E9Z7fDR39+4F2D/CSMHA52qBetWhwDJKTwKZPHAw46EI5Z1Q
TTfkpAyLMwdehFiONaxBKdbTvLZid8KjCdn8IOcX/vsF49iKm6kqDEOS1I+kZ5fv
EhrVaMQNvnosvvTd2txf0Bz7sRXGAOO16U3+PjDBhzOxmILhAKppUdKVhpZQMgCm
sb4Vq0a9ZPJdzipkYjhQWRk3i+MWBedfWDCPy1ndm84yNQafrXtVEQpXHel28MGn
eAxr33mWfHcnvSpB4jODtZLPVDZ6kJivEfnI4Xh+2F9PEGleJ/D5G6LTglKL9vnW
H25GpawZhdDwqeoCzYu92KgSnDPTBD+V4eRqTZh5OCOvl3jqhYfMaQRs529MeNlI
+l8yX19l+1SENIDfPOAWOI9ChP8Cfpg2iO9unffXcg35ElBRIysGmQj5Hd5NgL0W
r5mq8zLJYbujpzyAznPux6OzuXHd0iTe3eAWLLjWZFZK6xTKi2n8/3BYzwa0D1Ho
YWzREMsLAidGwKr9IAi15rdWA5/9aO1NJiGU1JhHfuoDx41iX9KH49e112em3P3L
fnnFI9j8IGN+tzKy9iAX
=+Ao2
-----END PGP SIGNATURE-----
--yrj/dFKFPuw6o+aM--
- Raw text -