X-Recipient: archive-cygwin AT delorie DOT com
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=LNQ/9Z1DzI0gzveiBULDRalbofv1hB4gtl60BN3eiqGM0DuCHXxPJ
	tPnrFH+ZR1YmD9sgzFPuuBIxCugO8zfClIZ4cSIvJensYkREq8AhfbwyqljPsdfH
	shW0mtBTgjOuGiOQkuHE/dZEiRRJp4D3mgYu2jwloAEpHz+0M4DhRM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; 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; s=default;
	 bh=mn0fb/oZsyFgIksRGUWnY3GwAFs=; b=H/nfueY78ntrG+fyM8m4okQG6sNx
	v3U73moYb9ePhRVCUSnzD8WhYsk1kuki6g/vO6/pFXkLNxwE4RJgrVnD3ZhyMPQz
	D+c5kShEgoR0iVlBQzWCZUalvfxQHhFNnSWSvNrGgyStPU9J8eO/0yuC2/Obi92p
	IRSttD2mGsUBoSo=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,KAM_RBL,RCVD_IN_PBL,RDNS_DYNAMIC,URIBL_BLACK autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 8 Dec 2015 16:34:38 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin multithreading performance
Message-ID: <20151208153438.GL22073@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5653B52B DOT 5000804 AT maxrnd DOT com> <20151126093427 DOT GJ2755 AT calimero DOT vinschen DOT de> <5656DDEF DOT 9070603 AT maxrnd DOT com> <5662C199 DOT 7040906 AT maxrnd DOT com> <CABPLAST5EnifrAQ2xKZmohKhyxQHh=K3x3DeCL+BTdHN8nN98w AT mail DOT gmail DOT com> <566367C8 DOT 5020703 AT maxrnd DOT com> <CABPLASSY3WWpHAeh=5gqRKdg85M8Wzkrq9qMaDhzhk2zvxgcOw AT mail DOT gmail DOT com> <5663EB9A DOT 40002 AT maxrnd DOT com> <CABPLASQZrDMnN32GG3-qRsnHhjsoroaY7ti1wx5uASDqdU7M+g AT mail DOT gmail DOT com> <5666B61F DOT 9050209 AT maxrnd DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="KIzF6Cje4W/osXrF"
Content-Disposition: inline
In-Reply-To: <5666B61F.9050209@maxrnd.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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