From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f196.google.com (mail-pl1-f196.google.com [209.85.214.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6BCD8213E85 for ; Thu, 9 Jan 2025 05:49:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.196 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736401752; cv=none; b=pnpPnTaJ/dZEDosBV1vO5ulQwqvW/0kvdsuW06jODOqJ/Dm8n1zNjVR2s+kIQkmCKw8cmvDatKf5XiVYekCqR1oH7A4mmkBHY2T/S7s6v92jS7jOEwer/rfWsjDGw0W/ZnFi4l1C+4j3Fsp0byvtHz5llQy08r4M7U19A9JiOZE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736401752; c=relaxed/simple; bh=Cjc0h+FN2W0rUZic7urfPMR8Z2JoC1LiAJjrV6AMd2w=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=PB77xepfyCTFHNJ/1TKbRjUpOpZ99e0XQrituUey2yRYEJrKwNCgLxpUrHzJI/nGviaYNLX2E22DoXhiEyqrICBWg+HVLyvSi+M6SwmMARJHxIzaBuQzv+pn5pVIHYLbcuZSxmNupRMERgo+J7MC7TyZsXSpgL8w8fiIe68Jp4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=TnQVhP1X; arc=none smtp.client-ip=209.85.214.196 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="TnQVhP1X" Received: by mail-pl1-f196.google.com with SMTP id d9443c01a7336-216281bc30fso9546155ad.0 for ; Wed, 08 Jan 2025 21:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736401749; x=1737006549; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HnqrsJ+oPEMychkJXRCs87TDHU8V8ApwFv6vd2gxMqE=; b=TnQVhP1XNHhXx0viI/ZSY835bv2oW3ft97pDy6lG7F8fr+/R3mLGeb6GAXgT4XE445 k4jVaj+8Ym24EQgZrbO8l2n/R/l4/UgeMO8FROhVpfJv+7deXri/0X1Oxst/T+0ZysnH FabPkfukg+LuYpUUt5eZS70OCU3rJoG/YylePv3G8fkTXmMTUohAg7GNmX7ofjud2xsj nOjJkk1xtNTCetBdzwy/tpElTExY/54VR/6tBOsBvLhjQdtpLqwZA1AZIWvQVxGidIy/ HkYXgtLFGCC7Am6zs+VCg/8FqTjpr+ZCO6jLU5GhWd2XlAASDdhsnCrS+KRLOPKaD0fB vXSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736401749; x=1737006549; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HnqrsJ+oPEMychkJXRCs87TDHU8V8ApwFv6vd2gxMqE=; b=MFQ6avze1sjc7t2kSuwVkyCX7OuRUK0p2mCJH46MTiWB1foGr8Mh2f2qvcM5hRJCBy miSmUFycMXf0D0FauiQ1otXcU9ZFU/C/8dpdJB/ZJOZpWb8TGRHOAJe47WV8jVnzQVdi GF8Vb0tyr332dsG6PdY/Xa0SlboG9qYH9PmDUXYu6LzncBJ7OpzT53D0dQGEER+np7bG SArDb7d9UYkNy5vJbfrkNtntXOALBlPj9aHyc33eT6Si5rJWOsvucmgTIfNFBobLQ9Ki TgD8QGra1GuALLP5TkVRKfpQerL5BRn3RyH9MixcqMSsahA9/Ri6kxusQvzZ/xBFcUQR C6Xg== X-Forwarded-Encrypted: i=1; AJvYcCWfj9lci4COeK+5MGVKmQbOGTYXsd9NbdjTShtK8o5BhiIjPACe5fuvrZvtFdigG9Oqs1EmLU99b855S7c=@vger.kernel.org X-Gm-Message-State: AOJu0Yxp/4FHn4fn09RRmb204A1Z0IJpVkaKbBELWZs7hqgBssY0iMo4 R8Ohm0myHWgobJClNeb6Bo4bAApM8HaREModN6ziP4FddweUpAPb X-Gm-Gg: ASbGncs871QJscMv+KgTApjhuhr0ABCVDIiQlXVsZ0VlXuVjFitEU+cR2YOOgZP0sb3 dZGz+3U1ppr6WLQNVXqmuVxjFUDzSp9lBpm9/v8+sRD56feEE/Ci2uVJwq7PLHZMqz5tUk+uf/o hxgM2QWOokHROW/PayW/VVv1dEK2XusPzoFkA9pLBr8y19vI6tpdyVGQqt5l76eZipN9V6Foc0N Ynimcv1pm7eGj0Ij5T9JULtE2/nxaUnYEhu1gFl5eoa6De2yBBAReee/ggDaSbf X-Google-Smtp-Source: AGHT+IHcdZSgZfvWiOy1T/84k36Ja8ZCqBQOQiWniBKKL1gfjbZnWVPw5Qup0W2KGf2ryUmdpIOfXw== X-Received: by 2002:a05:6a20:3948:b0:1e1:384e:20f1 with SMTP id adf61e73a8af0-1e88d1348dbmr9704594637.25.1736401748669; Wed, 08 Jan 2025 21:49:08 -0800 (PST) Received: from localhost.localdomain ([129.227.63.233]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72aad831160sm36284299b3a.59.2025.01.08.21.49.05 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 08 Jan 2025 21:49:08 -0800 (PST) From: zihan zhou <15645113830zzh@gmail.com> To: vincent.guittot@linaro.org Cc: 15645113830zzh@gmail.com, bsegall@google.com, dietmar.eggemann@arm.com, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, peterz@infradead.org, rostedt@goodmis.org, vschneid@redhat.com, yaowenchao@jd.com, yaozhenguo@jd.com Subject: Re: [PATCH V2] sched: Forward deadline for early tick Date: Thu, 9 Jan 2025 13:48:53 +0800 Message-Id: <20250109054852.92163-1-15645113830zzh@gmail.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Thank you for your reply! > > There are two reasons for tick error: clockevent precision and the > > CONFIG_IRQ_TIME_ACCOUNTING. with CONFIG_IRQ_TIME_ACCOUNTING every tick > > will less than 1ms, but even without it, because of clockevent precision, > > tick still often less than 1ms. In the system above, there is no such > > config, but the task still often takes more than 3ms. > > > > To solve this problem, we add a sched feature FORWARD_DEADLINE, > > consider forwarding the deadline appropriately. When vruntime is very > > close to the deadline, and the task is ineligible, we consider that task > > should be resched, the tolerance is set to min(vslice/128, tick/2). > > I'm worried with this approximation because the task didn't get the > slice it has requested because of the stolen time by irq or a shorter > tick duration Yes, you are right. forward deadline is not a good way, although the error is small, the task will have less exec time. > Yes but it also didn't say that you can move forward its deadline > before it has consumed its slice request. A task is only ensured to > get a discrete time quanta but can be preempted after each quanta even > if its slice has not elapsed. > > What you want, it's to trigger a need_resched after a minimum time > quanta has elapsed but not to update the deadline before the slice has > elapsed. > > Now the question is what is the minimum time quanta for us. Should it > be a tick whatever it's real duration for the task ? Should it be > longer ? I have also been thinking about this question: what is the appropriate minimum time quanta? I think neither tick nor slice is a good choice. The task should have an atomic runtime greater than tick to avoid frequent switching, but if the time size is silce, it is not flexible, tasks often use up the requested slice at once without caring about if they are eligible. So can we add a new kernel parameter, like sysctl_sched_min_granularity? Adding a min_granularity between tick and slice seems like a good choice. We can let a task exec min_granularity time at once, then it is needed to consider whether the task is eligible or whether the deadline needs to be updated. But I don't know how to handle wake up preemption more appropriately. Is it necessary to wait for the preempted task to complete an atomic time?