From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754000AbcIIKBC (ORCPT ); Fri, 9 Sep 2016 06:01:02 -0400 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37031 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752186AbcIIKA5 (ORCPT ); Fri, 9 Sep 2016 06:00:57 -0400 Date: Fri, 9 Sep 2016 12:00:41 +0200 From: luca abeni To: Tommaso Cucinotta Cc: Juri Lelli , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, linux-dl@retis.sssup.it Subject: Re: [PATCH] sched/deadline: document behavior of sched_yield() Message-ID: <20160909120041.2988e93a@utopia> In-Reply-To: <1473410650-30918-2-git-send-email-tommaso.cucinotta@sssup.it> References: <20160909074026.GC10409@e106622-lin> <1473410650-30918-1-git-send-email-tommaso.cucinotta@sssup.it> <1473410650-30918-2-git-send-email-tommaso.cucinotta@sssup.it> Organization: university of trento X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tommaso, On Fri, 9 Sep 2016 10:44:10 +0200 Tommaso Cucinotta wrote: [...] > +4.4 Behavior of sched_yield() > +----------------------------- > + > + When a SCHED_DEADLINE task calls sched_yield(), it gives up its > + remaining runtime and is suspended till the next reservation period, Maybe I am nitpicking, but I suspect "until" would be more appropriate than "till" :) More seriously: the concept of "reservation period" has not been defined in the document until now... So, I suspect this sentence should be rephrased using the concepts and terminology defined in the document... Maybe instead of saying that the task is suspended you can say that since the remaining runtime goes to 0 the task is immediately throttled, and will be able to execute again only after the time is equal to the scheduling deadline (as explained in "2. Scheduling algorithm"). Except for this, the patch looks good to me, thanks for documenting yield()! Thanks, Luca > + when its runtime will be replenished. This allows the task to > + wake-up exactly at the beginning of the next period. Also, this may > + be useful in the future with bandwidth reclaiming mechanisms, where > + sched_yield() will make the leftoever runtime available for > + reclamation by other SCHED_DEADLINE tasks. > + > + > 5. Tasks CPU affinity > ===================== >