Date: Mon, 18 Feb 2013 22:36:30 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Svatopluk Kraus <onwahe@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: [patch] i386 pmap sysmaps_pcpu[] atomic access Message-ID: <20130218203630.GO2598@kib.kiev.ua> In-Reply-To: <CAFHCsPXE-0-_SsYFYGdFnUDO6Hp9PErmq1kf3js87f2GZuTs6w@mail.gmail.com> References: <CAFHCsPUVTM9jfrnzY72YsPszLWkg-UaJcycTR4xXcS%2BfPzS1Vg@mail.gmail.com> <20130218150809.GG2598@kib.kiev.ua> <CAFHCsPVbkwj7fhqax5D5kk89VZgAjW9gT8uJunjevav2eTUbNQ@mail.gmail.com> <20130218170957.GJ2598@kib.kiev.ua> <CAFHCsPXE-0-_SsYFYGdFnUDO6Hp9PErmq1kf3js87f2GZuTs6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 > <kostikbel@gmail.com> 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 > >> <kostikbel@gmail.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130218203630.GO2598>