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.133.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 8326C33B975 for ; Wed, 28 Jan 2026 09:50:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769593843; cv=none; b=fTmdEP6BbIFuihZY09ZF83Ba+XYV5l2fxjMwS4ti42Ya5T64BYOOv1dND15acGWSzWHl3XAMbn9BaImAqvgRf37HhuCOC4cn4rHKGxr5mczH5KdoaHyxXbN63WK3socl0zZyiV79vixIae3Ka6wSgbKJrgzZvfqJhz2gzRaZSF4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769593843; c=relaxed/simple; bh=PQEiF8r8P9hGm/afNAaoJ7wn7IiuGrfi3afaM/Wvt28=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=nC8jcFxRf/OFo6H3JcG7T0kUTE7IgmXOgyICSIh+pLRhyEtAyrNADhG1NNnaZfIqj8JVvPQ0YhDYSvxYGewB0V4SsBTGcyMeUHWwhVKmsoYmTVAIFYkzhuDkIvEdwmkbd01PSu1Eeg5/v8pwas1EFSEIxeUr7XJugRnIDZsxk4I= 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=MXAiFLSM; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=IpMXRUj4; arc=none smtp.client-ip=170.10.133.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="MXAiFLSM"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="IpMXRUj4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769593841; 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=PQEiF8r8P9hGm/afNAaoJ7wn7IiuGrfi3afaM/Wvt28=; b=MXAiFLSMvti0d3Vft/SeGG04cHwrB/hV83CfZlRwOgVvMg8xtDU6ummKmNsVYUpqkxhqui BxIs/wgfZ4swD1bRIwhKjc+BKbBoIQ+D1MdKmMhsokTy3YgUHftprVkzjc4PwQgMWQYe5W XXSTCPWuhm+K3vjIZ8xcwjb5l3AP+1M= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-92-WYrSVv_1MzajhDOLCBscgg-1; Wed, 28 Jan 2026 04:50:40 -0500 X-MC-Unique: WYrSVv_1MzajhDOLCBscgg-1 X-Mimecast-MFC-AGG-ID: WYrSVv_1MzajhDOLCBscgg_1769593839 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-477c49f273fso71649965e9.3 for ; Wed, 28 Jan 2026 01:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769593839; x=1770198639; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=PQEiF8r8P9hGm/afNAaoJ7wn7IiuGrfi3afaM/Wvt28=; b=IpMXRUj42vRe8dVVB1y0lMlbBDQHhfbja6dTsiZ/DjNYPQc3nk7NZIfOU+XTGSOOeS eqhuWVsCLUiohc5fFsnk3UkHEAX7wz5SDpMRuwUZ3EZe1VrkJfC5kOkR/GxWx8+Pk1L+ GEnYZIbSjtg3ezuO0kmhbYqR+UcyCM2aYFf/tazTdspc8XAq8HgceISZxakTfCeHkU4F 9C44LqphQBkusHc51NyvKvOAXcXeB73D2m+pehTYdR3IJIgSmO6vigm+KAKvwWWg9maP BmwmqT7h0AFC06Lkl+m++3LXR4vf549CeL5Db64ed3eq3cTs+gqzvaC5IpVkOrzlJcso 2DlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769593839; x=1770198639; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=PQEiF8r8P9hGm/afNAaoJ7wn7IiuGrfi3afaM/Wvt28=; b=s5Dlw7Dg43W5iJ++KxZcBegJ41axAqihkqM7wFnARjzFhtzjlwfVQxygpLdmXZAv96 e0J7YbNWD1RcjuxUal6L/wwxskh0DptlaipYpJFXkwx+O6qTwkUb9X+/1mKaO4PKwBvX v+iIts14x5nvlTQaIqGCPUHtW8fr1WWIW5dtugs2OfxwSW1+gtHHP3pwB6U002txu6OC ae9AlO44IlWSuQj8geHIdPURui0iVyWfEXmtOqJprWTHkNOgnt4EhAYj2HSHgHLI/413 DjF2WTUVAzDLw8IoeF4l5rSsLJD6eN4qntvEZ6JrF/hijtAaj5otoesx8gSc1mlTTA5G hgUg== X-Forwarded-Encrypted: i=1; AJvYcCWmZBTy6yxduuV/x7NZi04KSTJIimf3UjZfMCxKDOVS7Crhtfkc1Rv11hku+RZpox+v1ifzwCB3pVA46e4=@vger.kernel.org X-Gm-Message-State: AOJu0YzV5iGEWHkVWBw5dXCchJd3uWVKzhxT8hktqStFWWHkyXcmZvQa sY6QDUulg1l7WIsyn02DKQ5Mu8x5fVFd5BF/kKTnpcEXFupdeHD0N2ubXbQYlheesK/dkpMQxGj 1VCBvDyGLlIndOnK+oo2k8X/K7yWKQmJLEYYKftNN/85pYJznR0V/UbC53hEcp2ymsQ== X-Gm-Gg: AZuq6aLMQTI45+GKZdfzOdxe9ktSzOH9SoNhQz08ibrY6NCQkSvgnZjAIhVzdBtG7To 2oXOw8Br8ycFaBHBH83mwQ1d0/G1PiW/OoifT1YlY2Vx6QabkUB89u2N/BDU0JaGdqR1mMibt/v KjlIg/PGqoSid3wH6RHmRggAZXmrPrztZD6GMqaBGuqxIh1t8lwPCK/x3V1lF7jkSZD9JWCoYMN pz+0mR1udjS46slAEONmI4Mc1jzihDhTDZFOddLvoLG2U+5HdlStJxnbDnJDdSTPgYz86XHIHJe OPr53k5iAY1YTroRnxOF/Lq/SfM8zom7VMtcQk4LXdXfNQq1CtO0vWO7qjVvkKJ4JqPrUPRP4ob SoIXnjg== X-Received: by 2002:a05:600c:4689:b0:477:c71:1fc1 with SMTP id 5b1f17b1804b1-48069c55610mr51648805e9.19.1769593838669; Wed, 28 Jan 2026 01:50:38 -0800 (PST) X-Received: by 2002:a05:600c:4689:b0:477:c71:1fc1 with SMTP id 5b1f17b1804b1-48069c55610mr51647885e9.19.1769593838043; Wed, 28 Jan 2026 01:50:38 -0800 (PST) Received: from [127.0.0.1] ([185.168.96.228]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10edfccsm5488885f8f.17.2026.01.28.01.50.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jan 2026 01:50:37 -0800 (PST) Date: Wed, 28 Jan 2026 09:50:36 +0000 From: Gabriele Monaco To: Andrea Righi Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tejun Heo , Joel Fernandes , David Vernet , Changwoo Min , Daniel Hodges , sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org Message-ID: <45e4dc7a-f261-46ec-8973-0fb8d1f7b0b9@redhat.com> In-Reply-To: References: <20260123161645.2181752-1-arighi@nvidia.com> <9b8c90b1-9247-4159-9bf6-72bd71bb74a2@redhat.com> Subject: Re: [PATCH v2] sched/deadline: Reset dl_server execution state on stop 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=UTF-8 Content-Transfer-Encoding: 7bit X-Correlation-ID: <45e4dc7a-f261-46ec-8973-0fb8d1f7b0b9@redhat.com> 2026-01-27T18:55:02Z Andrea Righi : > Unfortunately checking only runtime <= 0 isn't enough for the sched_ext DL > server case: > > # Runtime of EXT task (PID 2025) is 0.000000 seconds > # Runtime of RT task (PID 2026) is 4.990000 seconds > # EXT task got 0.00% of total runtime > not ok 2 FAIL: EXT task got less than 4.00% of runtime > > With the unconditional reset the EXT task gets 5% of the bandwidth. I'll > add some debugging to figure out exactly what is happening. Thanks for testing it. That's quite strange.. I run your test on a kernel without ext server, as far as I understand, the test is kinda indirectly checking also the fair server and that does not fail, right? At least that's what I get on an arm64 machine with 128 CPUs. After letting the test continue on failure I get: # # Runtime of FAIR task (PID 22503) is 0.240000 seconds # # Runtime of RT task (PID 22504) is 4.750000 seconds # # FAIR task got 4.81% of total runtime # ok 1 PASS: FAIR task got more than 4.00% of runtime # TAP version 13 # 1..1 # # Runtime of EXT task (PID 22511) is 0.020000 seconds # # Runtime of RT task (PID 22512) is 4.970000 seconds # # EXT task got 0.40% of total runtime # not ok 2 FAIL: EXT task got less than 4.00% of runtime # TAP version 13 # 1..1 # # Runtime of FAIR task (PID 22518) is 0.240000 seconds # # Runtime of RT task (PID 22519) is 4.750000 seconds # # FAIR task got 4.81% of total runtime # ok 3 PASS: FAIR task got more than 4.00% of runtime # TAP version 13 # 1..1 # # Runtime of EXT task (PID 22525) is 0.000000 seconds # # Runtime of RT task (PID 22526) is 4.990000 seconds # # EXT task got 0.00% of total runtime # not ok 4 FAIL: EXT task got less than 4.00% of runtime # ok 24 rt_stall # Mind that it's expected for the ext task to starve (I didn't apply the patches enabling the server). After adding all your patches [1], also the ext passes the test (i.e. gets boosted just fine). I tried disabling all CPUs but CPU0 and run the same test and it hung (bad sign), then I also enabled CPU1 (total 2 CPUs online) and again I see both fair and ext getting their share. What am I missing here? Thanks, Gabriele [1] - https://lore.kernel.org/lkml/20260126100050.3854740-1-arighi@nvidia.com