From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA7B43ACEE9 for ; Wed, 10 Jun 2026 09:21:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781083306; cv=none; b=c8b/P2AiZ+V99xjmClcqvO95HmooQHVIz95wn41NgPByc+qcQojxazg/I/IDYKiLWAnUQnxt6FwQX7Nx9TzUQfXNdPSbTKs7jSpipNYIanCfqsc1/9me2XIntMA8xkXNYcRyiEMk1bJZywOiA9gfDmDvP+OjBmxO3dnNngvN22g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781083306; c=relaxed/simple; bh=g5+W+jLy9btQjSDtxGia7H7MJP8ofhpJzo3kG4SNk7I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=svTo4IrU60C3yDzvWik1X1oLI36aFncAuEvNQZNTdmrzl3V+zOXANgvXQNOXh+BkeJtllstFq1TlLk2eVYyliWHLVwtLU5/MHiQu7TI1jOqyA9yJDGYY4mLYIDhlMj4xwBcyQ8etNGwdCN/ADF3uk4Uu+N0JJfYeMH72JvE2Yxk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ip4F6oRM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=P5XbKeil; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ip4F6oRM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="P5XbKeil" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781083303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lNoSE7CdhqapQyjtlFSi1j5OlaFx/mTNFdn28cYSfbk=; b=ip4F6oRMMiOhXrfupgSOfegNAiwzRQJ/XOo5pZ0ysq7G2HTBiEjUrfHmacY6JEmLGyMIpC +iIIInS/ejTUIutSFwcnCs65pBI4JGVUnjrSoa584Gtp2VapOrEZ0N5n5BxP0bUvTnIqW5 2yDAHO6L/bb+u73m031+djINBQLfNjM= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-167-aTfm6mpMMT6CIue5ga3Hog-1; Wed, 10 Jun 2026 05:21:42 -0400 X-MC-Unique: aTfm6mpMMT6CIue5ga3Hog-1 X-Mimecast-MFC-AGG-ID: aTfm6mpMMT6CIue5ga3Hog_1781083301 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-45ef55779d1so4040313f8f.0 for ; Wed, 10 Jun 2026 02:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1781083301; x=1781688101; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=lNoSE7CdhqapQyjtlFSi1j5OlaFx/mTNFdn28cYSfbk=; b=P5XbKeilyj6PjLc+j+bms2IePvgNd56oDnGCmNfcJBF4RytKWmPGWnFYUa9ewS/Gy8 CTG8FtAQzWymwV+Ioc3QBe8jS8XbG0w5vFHwUBNutXIk0YBEzvg+7iIX/t5aq7vohXPx ADMiKKpZPRrvx9w7NKWpeuTxAOuaGPKxi4K3Ngg4+OkzCvvoX/lxLLdrUHlVKd2plvmT DhpgQVA6O8IrHXy4El2L8hWSQaXF1jtx/aMp+hMiyYWOXECF3u6rLJYIEHrcBb0ySwJs 2KS4jXeuDpPBgjM9lxoVHuhgMEFE8mQoMiObTkyh8b7ssCHio5ZDvONLldsI29CI0ykB rISA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781083301; x=1781688101; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lNoSE7CdhqapQyjtlFSi1j5OlaFx/mTNFdn28cYSfbk=; b=m1mEZ3Bsv5hp4Nc0kSVhIB++Ytz1vIBKJkLu5phYou0vvaI91ngHFHtmDIeNE3kxfq 6FhkcLHusvwTcFfXncaiepkE5wjMsz8ArvYDcXT0ntgyR/NISWL+bRtigdjM8b7uopTv BCYm1J7hX/h/6GRZJEGhTQQrfF40gVC/+RkMg6m3gehNiQ7uFNIsEwmkXJSuAjnhZrrR TXFigqOhZlDaZ4RdlTGA+Uu11qgqupYkSb7FQq2jlik71vuBbNFCIUywvHtu+9cr21AY VEFlQ0ZcDNAbZyh7Qm/RZ3cViZj2baFTwA+ZfVti/S2wPvG4LGhs8ewOziMUWWx0bCPN UYjA== X-Forwarded-Encrypted: i=1; AFNElJ8UaC1z9aVCh2ocXlqLKSrKRqQ2niYEnaYR9BZOhwZ8WWlNotOVs9Y+3nUIsZ8WH8F3/p/dyu918qDDZtI=@vger.kernel.org X-Gm-Message-State: AOJu0Yzi9YQkxWClackCATBpfNUAAmHCeujcY/ttOGP7e2l28WsevU4S kpBr39yp+q2wAqzDzJdtYAGBYE/3A222miHBXcqteHoBZLdGKr2u85+sB7qWv4rFWt/tzRbsL4g 4Qr++1QSQ/n4saKRHG/q9xSLItckGSOZwes7+ypebKotAlMfj2rY1fA+u7Surxa9hrg== X-Gm-Gg: Acq92OEZetOH0Vf9KYxHBszYxrV/xtRzSyi2kwHfnicTO3aEmXzLpDMXLO2jcNw9bN0 DeQozu/QRymk/amTez2PrADwxAO6V5Yxm7tkNuAL6G6e+LkbGo4L6+TYXIlP9ct1+BPD89qnLWe dgHdsoncecNtDWjVYAD1mhMKnyR8T147Q9IdFmzdJX/Dso6+2BTNYNXBfUeltbk6MVwEV+q4gMy l/fyVBHUYRLe1k/LNZJTePyXnLTzf/+bvA3gHzZSgZmaekgEUmqainEF62vGyP62VkRIuA8vIGX rvgANsMzk4v2RuJm39YuDV0RlSUkEsUi/2S+ODHzydG+vC+IqglquErcUUKecZfrCwwVssc1x8c aIAgOT5S0EeltzrOdzjoPbHdi8GY5dX7sOhpc6XkTOvlq3mdPuy2a5ZG9mcEQIsI= X-Received: by 2002:a05:600c:1554:b0:490:7dfd:f7c2 with SMTP id 5b1f17b1804b1-490c25eaca1mr406762745e9.11.1781083301099; Wed, 10 Jun 2026 02:21:41 -0700 (PDT) X-Received: by 2002:a05:600c:1554:b0:490:7dfd:f7c2 with SMTP id 5b1f17b1804b1-490c25eaca1mr406762205e9.11.1781083300690; Wed, 10 Jun 2026 02:21:40 -0700 (PDT) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.95.181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f35eae5sm70938593f8f.33.2026.06.10.02.21.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 02:21:40 -0700 (PDT) Date: Wed, 10 Jun 2026 11:21:37 +0200 From: Juri Lelli To: Yuri Andriaccio Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tejun Heo , Johannes Weiner , Michal =?iso-8859-1?Q?Koutn=FD?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Luca Abeni , Yuri Andriaccio Subject: Re: [RFC PATCH v6 00/25] Hierarchical Constant Bandwidth Server Message-ID: References: <20260608121546.69910-1-yurand2000@gmail.com> <9c0d3d19-5c14-42e0-b29d-4ea32d9e624f@santannapisa.it> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9c0d3d19-5c14-42e0-b29d-4ea32d9e624f@santannapisa.it> On 09/06/26 18:23, Yuri Andriaccio wrote: > Hi Juri, > > Thanks for looking into this. > > > I started playing with the new interface and ended up with the following > > > > bash-5.3# cat cpu.rt.max  (root) > > 10000 100000 > > bash-5.3# cat g1/cpu.rt.max > > 10000 100000 > > bash-5.3# cat g1/cpu.rt.internal > > 9999 100000 > > > > which looks odd to me, as nothing is running on g1 yet and no children > > groups either. Maybe a rounding error of some kind? > > You are right. I should have mentioned that it is just a rounding error that > occurs when converting from a bandwidth value to a runtime value. This > happens because the tg_rt_internal_bandwidth() function truncates the value > when transforming the runtime from nanoseconds to micros. Rounding could be > used here to report a more accurate value. > > This same issue is probably found in the from_ratio() function, which has a > similar truncation issue when converting from bandwidth to runtime, but > since it is working in the nanoseconds range it might not be that big of a > problem. The value from from_ratio() is used for the setup of the dl_servers > even when the children bw is zero, so maybe it is possible to add a special > case? > > Anyways, as it is right now, the cpu.rt.internal may have only a +1/-1us > error in reporting the actual used values, while the error for the runtime > value used internally to setup the dl_servers is in the range of tens of > nanoseconds. Not a huge problem per se, but it will raise some eyebrows (and generate questions) if we leave things as is, I fear. I wonder if, instead of converting to bandwidth ratios and back (losing precision in both directions), we can compute children's runtime sum directly in nanoseconds. For children with different periods, we can maybe normalize (128-bit intermediate?). Parent's internal runtime is then a simple exact subtraction: parent_runtime - children_runtime_sum. This should reduce precision loss from double conversions. Also, as you suggest as well, apply rounding when displaying to user.