DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=sQ2Xg8s8Q7l7eRmm1zY6+ZsejLdEE3Is+tvUFvgSf9J6k2QjLzKkV
	D37tQ065XO4GNLBH6oy3zro7Xr4NsbX3h9wpVfp4xRT2uEHmGN0Sl4DWKh1zwiT5
	sDbN0eA4ZEAvkMtQ/hee2cq42IaPyXWJb7gFfib0U9TJYTAs/tRI9A=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Tue, 8 Dec 2015 18:02:44 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Cygwin multithreading performance
Message-ID: <20151208170244.GA10155@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20151126093427.GJ2755@calimero.vinschen.de> <5656DDEF.9070603@maxrnd.com> <5662C199.7040906@maxrnd.com> <CABPLAST5EnifrAQ2xKZmohKhyxQHh=K3x3DeCL+BTdHN8nN98w@mail.gmail.com> <566367C8.5020703@maxrnd.com> <CABPLASSY3WWpHAeh=5gqRKdg85M8Wzkrq9qMaDhzhk2zvxgcOw@mail.gmail.com> <5663EB9A.40002@maxrnd.com> <CABPLASQZrDMnN32GG3-qRsnHhjsoroaY7ti1wx5uASDqdU7M+g@mail.gmail.com> <5666B61F.9050209@maxrnd.com> <20151208153438.GL22073@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
In-Reply-To: <20151208153438.GL22073@calimero.vinschen.de>
User-Agent: Mutt/1.5.23 (2014-03-12)

--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--