From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62836 invoked by alias); 8 Dec 2015 15:34:45 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 62773 invoked by uid 89); 8 Dec 2015 15:34:45 -0000 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 Received: from ipbcc02fe8.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.47.232) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Dec 2015 15:34:41 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 92E5AA80613; Tue, 8 Dec 2015 16:34:38 +0100 (CET) Date: Tue, 08 Dec 2015 15:34:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Cygwin multithreading performance Message-ID: <20151208153438.GL22073@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <5653B52B.5000804@maxrnd.com> <20151126093427.GJ2755@calimero.vinschen.de> <5656DDEF.9070603@maxrnd.com> <5662C199.7040906@maxrnd.com> <566367C8.5020703@maxrnd.com> <5663EB9A.40002@maxrnd.com> <5666B61F.9050209@maxrnd.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) X-SW-Source: 2015-12/txt/msg00101.txt.bz2 --KIzF6Cje4W/osXrF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2685 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 Content-length: 819 -----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--