From owner-freebsd-current@FreeBSD.ORG Mon Feb 18 20:36:34 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD17A2C4 for ; Mon, 18 Feb 2013 20:36:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2B6996BB for ; Mon, 18 Feb 2013 20:36:33 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1IKaUiO071593; Mon, 18 Feb 2013 22:36:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1IKaUiO071593 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1IKaUjY071592; Mon, 18 Feb 2013 22:36:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 18 Feb 2013 22:36:30 +0200 From: Konstantin Belousov To: Svatopluk Kraus Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130218203630.GO2598@kib.kiev.ua> References: <20130218150809.GG2598@kib.kiev.ua> <20130218170957.GJ2598@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ickEXl+ukcSQ/3E" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 20:36:34 -0000 --4ickEXl+ukcSQ/3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 18, 2013 at 09:27:40PM +0100, Svatopluk Kraus wrote: > On Mon, Feb 18, 2013 at 6:09 PM, Konstantin Belousov > wrote: > > On Mon, Feb 18, 2013 at 06:06:42PM +0100, Svatopluk Kraus wrote: > >> On Mon, Feb 18, 2013 at 4:08 PM, Konstantin Belousov > >> wrote: > >> > On Mon, Feb 18, 2013 at 01:44:35PM +0100, Svatopluk Kraus wrote: > >> >> Hi, > >> >> > >> >> the access to sysmaps_pcpu[] should be atomic with respect to > >> >> thread migration. Otherwise, a sysmaps for one CPU can be stolen by > >> >> another CPU and the purpose of per CPU sysmaps is broken. A patch is > >> >> enclosed. > >> > And, what are the problem caused by the 'otherwise' ? > >> > I do not see any. > >> > >> The 'otherwise' issue is the following: > >> > >> 1. A thread is running on CPU0. > >> > >> sysmaps =3D &sysmaps_pcpu[PCPU_GET(cpuid)]; > >> > >> 2. A sysmaps variable contains a pointer to 'CPU0' sysmaps. > >> 3. Now, the thread migrates into CPU1. > >> 4. However, the sysmaps variable still contains a pointers to 'CPU0' s= ysmaps. > >> > >> mtx_lock(&sysmaps->lock); > >> > >> 4. The thread running on CPU1 locked 'CPU0' sysmaps mutex, so the > >> thread uselessly can block another thread running on CPU0. Maybe, it's > >> not a problem. However, it definitely goes against the reason why the > >> submaps (one for each CPU) exist. > > So what ? >=20 > It depends. You don't understand it or you think it's ok? Tell me. >=20 Both. I do not understand your concern, and I think that the code is fine. Both threads in your description make useful progress, and computation proceeds correctly. >=20 > >> > >> > >> > Really, taking the mutex while bind to a CPU could be deadlock-prone > >> > under some situations. > >> > > >> > This was discussed at least one more time. Might be, a comment sayin= g that > >> > there is no issue should be added. > >> > >> I missed the discussion. Can you point me to it, please? A deadlock is > >> not problem here, however, I can be wrong, as I can't imagine now how > >> a simple pinning could lead into a deadlock at all. > > Because some other load on the bind cpu might prevent the thread from > > being scheduled. >=20 > I'm afraid I still have no idea. On single CPU, a binding has no > meaning. Thus, if any deadlock exists then exists without binding too. > Hmm, you are talking about a deadlock caused by heavy CPU load? Is it > a deadlock at all? Anyhow, mutex is a lock with priority propagation, > isn't it? >=20 When executing on single cpu, kernel sometimes make different decisions. Yes, the deadlock can be more precisely described as livelock. It might not make any matter for exactly this case, but still is useful to remember. --4ickEXl+ukcSQ/3E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRIpDNAAoJEJDCuSvBvK1BOtkP/36bapDMkUKdt8xwGxgDNstB OzAHtfGsIgHKnkk3vbFlAFyL40+6ifHOnFpEeq/wdKe8Dcj7TX11brlDa9BG7rzX MWimfwmhLA2tfodraRTN6pMteMTFva2kIgyBS2UYT1lxhI3txnuhfP4H4IzZd2gR QCG1gAu28RXv61B4lKbBS4b5enXwDkV5YO9b6Wn57IC3FoXYLY09pSBSYT8pB96n 2ApV/vFN8C2EzPE5ISG9FQLVRCcIUvpTwu5+E0OLPZj7KWUcxfhecuowkOzyanvu vETWYswmSlJIQJvOWEUgyjSRKCAOXTG19KiFwEEDV9Tcq4HRUolxy4AmYMwWG92+ MKxBlBAr1hQFfy+bY/zotFAVcvq7uWXpmolMreNQGNneQNCeDVj7CvIRyS/H4yA7 jMDQqR27QV9kZhQS449+cT84f5CShNzyRO8+brT7cLOSYF7NYoEhQCbmlcHcOXaH BAZYDtfwYYz9GmgHdU9JgyqcWEARAv9LuCJNLr4/EbC3yzzYF1Gs05qhnW2pfGCe dJuxJlwihqR4oj6iudO06GuukZ/K2/payLCKuXmKQwk1Fry0MlpNH7qLLj8mx58h +Lu5AKrfK/JhFRRW6TWGQ5GMrg0vAy7jI5AcaQ/oCzySna9wEkO25QSFHLyvGtwe XchettfJnn+anLvwug9q =mp0d -----END PGP SIGNATURE----- --4ickEXl+ukcSQ/3E--