From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CC0BDC4332F for ; Tue, 7 Nov 2023 16:47:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232720AbjKGQrh (ORCPT ); Tue, 7 Nov 2023 11:47:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48458 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229521AbjKGQrf (ORCPT ); Tue, 7 Nov 2023 11:47:35 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8A4B93 for ; Tue, 7 Nov 2023 08:47:33 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D1D8C433C7; Tue, 7 Nov 2023 16:47:31 +0000 (UTC) Date: Tue, 7 Nov 2023 11:47:32 -0500 From: Steven Rostedt To: Joel Fernandes Cc: Daniel Bristot de Oliveira , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org, Luca Abeni , Tommaso Cucinotta , Thomas Gleixner , Vineeth Pillai , Shuah Khan , Phil Auld Subject: Re: [PATCH v5 6/7] sched/deadline: Deferrable dl server Message-ID: <20231107114732.5dd350ec@gandalf.local.home> In-Reply-To: References: X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 6 Nov 2023 16:37:32 -0500 Joel Fernandes wrote: > Say CFS-server runtime is 0.3s and period is 1s. > > At 0.7s, 0-laxity timer fires. CFS runs for 0.29s, then sleeps for > 0.005s and wakes up at 0.295s (its remaining runtime is 0.01s at this > point which is < the "time till deadline" of 0.005s) > > Now the runtime of the CFS-server will be replenished to the full 0.3s > (due to CBS) and the deadline > pushed out. > > The end result is, the total runtime that the CFS-server actually gets > is 0.595s (though yes it did sleep for 5ms in between, still that's > tiny -- say if it briefly blocked on a kernel mutex). That's almost > double the allocated runtime. > > This is just theoretical and I have yet to see if it is actually an > issue in practice. Let me see if I understand what you are asking. By pushing the execution of the CFS-server to the end of its period, if it it was briefly blocked and was not able to consume all of its zerolax time, its bandwidth gets refreshed. Then it can run again, basically doubling its total time. But this is basically saying that it ran for its runtime at the start of one period and at the beginning of another, right? Is that an issue? The CFS-server is still just consuming it's time per period. That means that an RT tasks was starving the system that much to push it forward too much anyway. I wonder if we just document this behavior, if that would be enough? -- Steve