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 5FA19C4332F for ; Wed, 8 Nov 2023 02:42:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235307AbjKHCmW (ORCPT ); Tue, 7 Nov 2023 21:42:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229503AbjKHCmU (ORCPT ); Tue, 7 Nov 2023 21:42:20 -0500 Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28371184 for ; Tue, 7 Nov 2023 18:42:18 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id ca18e2360f4ac-7ad501764f4so118943539f.3 for ; Tue, 07 Nov 2023 18:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1699411337; x=1700016137; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=l0/YVAel4Gttz4i2ZT43a1gG1mnikYVH5WxWUT8rkkA=; b=X3IRmnQBd3UijRz2S8HIOYIOvuFYHMaBGZ+mKP2ErA9xJfEcCS1TXT9nCWTg+ZpHnm mfB5bAYgVi8+GOGCFgvY3cune1fTdlNXgl+17em80ChbNeU8AtBOGOVTQ9lSCF+7rP1/ dRftoH/NELbyQ66eXUFMTMNKv4EIPSHe1itP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699411337; x=1700016137; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=l0/YVAel4Gttz4i2ZT43a1gG1mnikYVH5WxWUT8rkkA=; b=VhDcjAFibo32+4OAjWc4RvejicmgTRMN6yVOnRX1hgCb7NT0ZTMol2vC/CNHS5jY10 zAX/oIDXKiMc6PMNsunIUSqD1NFFBuhJQNQCpclwJqCjvAL776tceQXP0lIAmHEn7KcZ ALlgRzsdGsFCK5Uea9HTaAPcp9lVTssJ463UCaGbfXzvWovrSg8Ze59z4CO8Tas+CxoO LMCvC4epk6g/D0O5h83ssyeBWLasAFWtLh3aVwcvsLWqi9xX1C0Ul2qcxgv5u8YNoaFg 0Xjh/oQX8/rUQhzMydzUIYXCHic8SN88vT/a6yv4nQI4LkLW0NNNUROeMdT4HUlyXyKH B3tw== X-Gm-Message-State: AOJu0Yyn5CcCjpjwuif58gb9vyoLn/s5TRfkRGNyPdWXxfIbOWEIY0pn InSr9aX9MFVXqINfT2lwdJMdbA== X-Google-Smtp-Source: AGHT+IGIIe2W7d5LVTX6AoRFW05ZsrY22EQeoefXPK016WTBYYH6khHyH8shA8THqOmVsKy3XSIzLw== X-Received: by 2002:a5d:9282:0:b0:794:efb0:83d6 with SMTP id s2-20020a5d9282000000b00794efb083d6mr742434iom.12.1699411337472; Tue, 07 Nov 2023 18:42:17 -0800 (PST) Received: from localhost (20.10.132.34.bc.googleusercontent.com. [34.132.10.20]) by smtp.gmail.com with ESMTPSA id ft8-20020a056638660800b00452e02e784fsm3052078jab.144.2023.11.07.18.42.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 18:42:16 -0800 (PST) Date: Wed, 8 Nov 2023 02:42:16 +0000 From: Joel Fernandes To: Daniel Bristot de Oliveira Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , 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: <20231108024216.GB2992223@google.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 07, 2023 at 12:58:48PM +0100, Daniel Bristot de Oliveira wrote: [...] > >> One more consideration I guess is, because the server is throttled > >> till 0-laxity time, it is possible that if CFS sleeps even a bit > >> (after the DL-server is unthrottled), then it will be pushed out to a > >> full current deadline + period due to CBS. In such a situation, if > >> CFS-server is the only DL task running, it might starve RT for a bit > >> more time. > >> > >> Example, say CFS 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 3s (due to CBS) and the deadline > >> pushed out. The end result is the total runtime that the CFS-server > >> actually gets is 0.0595s (though yes it did sleep for 5ms in between, > >> still that's tiny -- say if it briefly blocked on a kernel mutex). > > > > Blah, I got lost in decimal points. Here's the example again: > > > > 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. > > I think I got what you mean, and I think I took for granted that we were > doing overload control on the replenishment, but it seems that we are not.. > > I just got back from a doct appt, I will do a proper reply later today. Ah ok! Thanks Daniel! And hope the appointment went well. - Joel