From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751999AbcF0K13 (ORCPT ); Mon, 27 Jun 2016 06:27:29 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:34213 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751511AbcF0K10 (ORCPT ); Mon, 27 Jun 2016 06:27:26 -0400 Date: Mon, 27 Jun 2016 18:31:25 +0800 From: Boqun Feng To: Peter Zijlstra Cc: panxinhui , 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: <20160627103125.GF6512@insomnia> References: <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> <20160627064506.GE6512@insomnia> <20160627080959.GU30154@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hOcCNbCCxyk/YU74" Content-Disposition: inline In-Reply-To: <20160627080959.GU30154@twins.programming.kicks-ass.net> 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 --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 27, 2016 at 10:09:59AM +0200, Peter Zijlstra wrote: [snip] >=20 > No, this is entirely insane, also broken. >=20 > No vectors, no actual function calls, nothing like that. You want the > below to completely compile away and generate the exact 100% same code > it does today. >=20 Point taken. As Xinhui also posted something similar, which worked better on not effecting the generated code if not enabled. I think I'd better to drop this workload to him ;-) > > +++ b/kernel/locking/osq_lock.c > > @@ -1,6 +1,7 @@ > > #include > > #include > > #include > > +#include > > =20 > > /* > > * An MCS like lock especially tailored for optimistic spinning for sl= eeping > > @@ -87,6 +88,8 @@ bool osq_lock(struct optimistic_spin_queue *lock) > > struct optimistic_spin_node *prev, *next; > > int curr =3D encode_cpu(smp_processor_id()); > > int old; > > + int loops; > > + long vpc; > > =20 > > node->locked =3D 0; > > node->next =3D NULL; > > @@ -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; >=20 > That's just nasty, and could result in an unconditional decrement being > issues, even though its never used. >=20 Right, better to calculate this decrement at the argument of vcpu_is_preempted() callsite, and define the primitive of host code as #define vcpu_is_preempted(cpu) false , which could probably be optimized out. Regards, Boqun > > + vpc =3D vcpu_preempt_count(); > > + > > /* > > * Normally @prev is untouchable after the above store; because at th= at > > * 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 > > cpu_relax_lowlatency(); > >=20 --hOcCNbCCxyk/YU74 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXcQBvAAoJEEl56MO1B/q43d4H/j8iFF6OTdjzMOHuDo5a46oE WorZQ21kVuRS51TFv7i6Q8KdxfX3uTIHCNHshzhf2scBVeM7x0YbIRpMRDLNZUh6 oj03rwekY+geDZUgVqB1xBrAwUBW8VZh+8mXJorNZ865TTOaBfLEJUtPheSdh49B CMATVbmlWq/P0+IOrF0VIac+ZwUR6N49hJeZttS9ucg0QuWvR9z8RdAbA3YxOo/n 8Gv3/o55W/U0IuA4nUOP8tmXTR4oYMA3t9g8xTRsKIG5EW9TJpVjapsM0CqZLOBB PfgXgPw3Y7t8KGfKENS61zOloebTIE3C35uFmFFO0VLpJvvUkdOLlseiTggINGU= =qdMy -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74--