From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934870AbbKTOJZ (ORCPT ); Fri, 20 Nov 2015 09:09:25 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:35219 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760069AbbKTOJU (ORCPT ); Fri, 20 Nov 2015 09:09:20 -0500 Date: Fri, 20 Nov 2015 22:08:50 +0800 From: Boqun Feng To: Peter Zijlstra Cc: Paul Turner , Ingo Molnar , Oleg Nesterov , LKML , Paul McKenney , Jonathan Corbet , mhocko@kernel.org, dhowells@redhat.com, Linus Torvalds , will.deacon@arm.com Subject: Re: [PATCH 2/4] sched: Document Program-Order guarantees Message-ID: <20151120140850.GA19693@fixme-laptop.cn.ibm.com> References: <20151102132901.157178466@infradead.org> <20151102134940.883198067@infradead.org> <20151120100230.GA17308@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: <20151120100230.GA17308@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Peter, On Fri, Nov 20, 2015 at 11:02:30AM +0100, Peter Zijlstra wrote: [snip] > + * BLOCKING -- aka. SLEEP + WAKEUP > + * > + * For blocking we (obviously) need to provide the same guarantee as for > + * migration. However the means are completely different as there is no lock > + * chain to provide order. Instead we do: > + * > + * 1) smp_store_release(X->on_cpu, 0) > + * 2) smp_cond_acquire(!X->on_cpu) > + * > + * Example: > + * > + * CPU0 (schedule) CPU1 (try_to_wake_up) CPU2 (schedule) > + * > + * LOCK rq(0)->lock LOCK X->pi_lock > + * dequeue X > + * sched-out X > + * smp_store_release(X->on_cpu, 0); > + * > + * smp_cond_acquire(!X->on_cpu); > + * X->state = WAKING > + * set_task_cpu(X,2) > + * > + * LOCK rq(2)->lock > + * enqueue X > + * X->state = RUNNING > + * UNLOCK rq(2)->lock > + * > + * LOCK rq(2)->lock // orders against CPU1 > + * sched-out Z > + * sched-in X > + * UNLOCK rq(1)->lock > + * > + * UNLOCK X->pi_lock > + * UNLOCK rq(0)->lock > + * > + * > + * However; for wakeups there is a second guarantee we must provide, namely we > + * must observe the state that lead to our wakeup. That is, not only must our > + * task observe its own prior state, it must also observe the stores prior to > + * its wakeup. > + * > + * This means that any means of doing remote wakeups must order the CPU doing > + * the wakeup against the CPU the task is going to end up running on. This, > + * however, is already required for the regular Program-Order guarantee above, > + * since the waking CPU is the one issueing the ACQUIRE (2). > + * Hope I'm the only one who got confused about the "2" in "ACQUIRE (2)", what does that refer? "2) smp_cond_acquire(!X->on_cpu)"? The comments are great, just try to understand your meaning here ;-) Regards, Boqun > + */ > + > /** > * try_to_wake_up - wake up a thread > * @p: the thread to be awakened --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJWTylsAAoJEEl56MO1B/q4k3QH/jhQWaHALaqaKxohSEVoSLAz YWNcsSaqTQ3r0eq6TTDHhJdlRUobMqRHwbQTJVQyukP8G5Nuzheu/d8bJxZq8lLu f9xigPiwbiwLkglS8Y7E3uNtMNqYJxmQI8JA2dmUwG5ZQ44Y9RFnMISO1hhk0mK6 rwg/qq+OS1v5KeLnODhq8OzryM0t8YcT+gttxlAjR5DEeJIY7I2x6BQK/ppMz6sj ax0qrX8C2c7vtbtNCWXEBukgaL9nE7Yy652SqZvKm+9pVkDcJu7Cvk0oXq9GLLcA 1KLI8OkK+xsRVCjcsWZM0zKFbguWPDgRs2+2UJl780wxUtzNguIuP5rRCwxQ05A= =z1QM -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--