From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752125AbcFZOZV (ORCPT ); Sun, 26 Jun 2016 10:25:21 -0400 Received: from mail-it0-f46.google.com ([209.85.214.46]:37871 "EHLO mail-it0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751978AbcFZOZT (ORCPT ); Sun, 26 Jun 2016 10:25:19 -0400 Date: Sun, 26 Jun 2016 22:29:22 +0800 From: Boqun Feng To: panxinhui Cc: Peter Zijlstra , Pan Xinhui , linux-kernel@vger.kernel.org, mingo@redhat.com, dave@stgolabs.net, will.deacon@arm.com, Waiman.Long@hpe.com, benh@kernel.crashing.org Subject: Re: [PATCH] locking/osq: Drop the overload of osq lock Message-ID: <20160626142922.GD6512@insomnia> References: <20160625142447.GK30154@twins.programming.kicks-ass.net> <20160625152130.GA2452@insomnia> <20160625161540.GM30154@twins.programming.kicks-ass.net> <20160625164527.GD2384@insomnia> <20160625192025.GP30154@twins.programming.kicks-ass.net> <20160626061057.GA6512@insomnia> <20160626065926.GB6512@insomnia> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pvezYHf7grwyp3Bc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --pvezYHf7grwyp3Bc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 26, 2016 at 03:08:20PM +0800, panxinhui wrote: [snip] > > @@ -106,6 +109,9 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > node->prev =3D prev; > > WRITE_ONCE(prev->next, node); > >=20 > > + old =3D old - 1; > > + vpc =3D vcpu_preempt_count(); > > + > > /* > > * Normally @prev is untouchable after the above store; because at that > > * moment unlock can proceed and wipe the node element from stack. > > @@ -118,8 +124,14 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > while (!READ_ONCE(node->locked)) { > > /* > > * If we need to reschedule bail... so we can block. > > + * An over-committed guest with more vCPUs than pCPUs > > + * might fall in this loop and cause a huge overload. > > + * This is because vCPU A(prev) hold the osq lock and yield out, > > + * vCPU B(node) wait ->locked to be set, IOW, wait till > > + * vCPU A run and unlock the osq lock. > > + * NOTE that vCPU A and vCPU B might run on same physical cpu. > > */ > > - if (need_resched()) > > + if (need_resched() || vcpu_is_preempted(old) || vcpu_has_preempted(v= pc)) > > goto unqueue; > >=20 >=20 > the prev might change, so we need read node->prev every loop, then check= vcpu preempted. >=20 Right you are on the possibility of the prev's change, however, even if we reread node->prev, the prev is still not stable after we read, that is the prev can change after we read in the loop and before we check the vcpu preemption in the next loop, therefore whether the reread is worthwhile, depends on some real tests I think. Regards, Boqun > > cpu_relax_lowlatency(); >=20 --pvezYHf7grwyp3Bc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXb+a+AAoJEEl56MO1B/q40dkH/2sJu3XnXTs1Lj9+5oVZ4ZGF jh9Uq/3+Zp6bePvGTGJgXggGqnbbfSIm3xuQlmxF/JBkw0ZFFQJgtzZ8hgDFX65O G0pnfL49mGyukyX5wIlMoMF6MPY3tw+Z/KVyh3dOZpx0kx2T4fYDLCFYxk4pLW/3 9axjyXlCAZJrrdC1tSxiOe60/FPg9+ZVas6P8qIlXpgUWgP8GabhtC5BoUOeodBJ TC4+58klEgnaE5tKCiX/tU8THiVDRpeAVMrSvg+qewy6UH4RByMpqDk4fJWVxeeh DfTkGSJLukyW6mVF9zFAZEdm6upNiKPYRmZhTAbfXVGbSLecU+XaHy472qPYulQ= =Z924 -----END PGP SIGNATURE----- --pvezYHf7grwyp3Bc--