From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193]) (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 2535E157E88 for ; Thu, 16 Jan 2025 08:13:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737015194; cv=none; b=tSXBWDxB9ZWTN3BILVx05sUFBxG+4PdLErbROCxQmRshAYJCLVXeS9NepFrT/JIeNUGNMpJBMyFkSAPxXfk3iIJuiHmrm64J5OG2dJl9VAnup/BxqWKb4bfLDHfs5oKi9ndM4YHXQ+wvMkIzBjA7Z2FJakog05a7pEBzzYKGXLc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737015194; c=relaxed/simple; bh=0VAXwnmzCJD2YJ/lfXbFX17jEZBNRjmhv2OPzDM7ZxU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=IOJ4DFMxNbyAvoBFiLUreWZLDKca1Jcjl40X7W8prxfKCUnYlFHPp6TSXTy42Iy7j796zsFChfRXnazmAiMM/0JewiNWggL3XupyzX6I4h0caYOwPAGa1QWhJ2R3Yzj4tj3acZhcQVTY3fhKDFsBA6j2u+0UcniWe8ORuSJVEGI= 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=lFd9mSAv; arc=none smtp.client-ip=209.85.214.193 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="lFd9mSAv" Received: by mail-pl1-f193.google.com with SMTP id d9443c01a7336-2161eb95317so9991615ad.1 for ; Thu, 16 Jan 2025 00:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737015192; x=1737619992; 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=WyR0gOLY261LmGIWi85A9YEFi6PyYM+YSDVrNk1uxPI=; b=lFd9mSAvOpYYKkyAijgHi+BOFoyhbD6gn3HhrXVfpULo+0HPi8GvFFca6Z5LZzeXup va+tfhYZFDDzkKhml3G3Qds0GGkjRzn0pYbR6fleixPdjpO6fSEgQDRyWyfkybvjUCSE A+JEZZmPnOreLUys3TRCzLpbxiSh4qUphYtYTvR3F0o9SE84qeaM0A+LFwW8johvfaqk m17ub+YZkY8HbHKkSwHk4MT5uMGRVOjZ6dy8TgbuQWNrIkumuuvkEmrmMUCwEzK4Qe0C vM0TTaQ6WLudytUwIWRQi8SP/74os15cAxkgWPwiQUGIkd0gbIfIvP35As34/DM2zmvt LpkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737015192; x=1737619992; 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=WyR0gOLY261LmGIWi85A9YEFi6PyYM+YSDVrNk1uxPI=; b=HxWqFpAVNLHb4+lGcijnemV3iqqhfsJ2QWNxrQa4hNOcbseZWqSkHz6VGpxAVoB73F t5vuDn4iS8LLlKAtp8M/0PMfnFJRPxCraj8GANGbnYDPNc5oEMu5IouX11Y50z+J52X2 AuGyVNcltZyVPESaeFfxnoIo0VWIlxqEmh/83a0bdq7zup/Lz7hUC8rE3Il7rGF3Jm4e 4ceQvndvMepdgK8YEEmQ7Y/BrU8mHasBSrevhZebCCN8wTRnPXVInHhSH7yciTyo9VK7 w+hji2Ro5I3KlmzdTfj24lluC6DhkAYMtNLlMiM0JU345Lf53dI8R7wLOk3ys3W+b7P8 q7RA== X-Forwarded-Encrypted: i=1; AJvYcCVx33qIVwqIpZ7uxioPa/MZ3QLopKm3J5q2bohg9AeGDa+BbXGooJQhfk0eSMN/6uI49W0Qy5YgM0xZlEY=@vger.kernel.org X-Gm-Message-State: AOJu0Yzb0vyhrNy2/sCbhIl73qBX+MCEJp3vEmaL6VIzWRami1JiXdFD Fs+76TBTeu/ekp1PQwK2gUwtH66fwuaRqJKSSZFaj/HAEOm1N6m1 X-Gm-Gg: ASbGncvci28SAWyYsqzxOM+0jKHB0UCl1UV3JAi+OpPbn8ur8UifxYh9dXe6eUIz6EX 811Czs5QRddwA89J8xrvOXNSdKjUG39INYswwIBb9yGOwmaEf3f4pO5UZyvf1CIm2JNtWb5s4j/ 3NoP5pbRudlZNiejkYYJnE3vUpEbOOptnSgGHcZtLqYGItMZ7aAIFu7b9Of7VFCEkOz/PK2OZx3 tWIymBhPb7U81tafrvPITDEPA0JWE16I11cQ7dqrlTX/L+LENls8bvCweYMA4gIPQNj7K9QJpST X-Google-Smtp-Source: AGHT+IF+fn0QQgy5j9B2o+rVZLXjhAnNL3RhWiBBk1qe11EIGUwK7uCZcy1uiXhzqY7VO6rDZZEPfw== X-Received: by 2002:a05:6a00:392a:b0:725:b347:c3cc with SMTP id d2e1a72fcca58-72d2200273bmr46652887b3a.23.1737015192312; Thu, 16 Jan 2025 00:13:12 -0800 (PST) Received: from localhost.localdomain ([114.67.205.189]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72d4056a5ddsm10652967b3a.52.2025.01.16.00.13.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 00:13:11 -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, 16 Jan 2025 16:12:35 +0800 Message-Id: <20250116081234.16222-1-15645113830zzh@gmail.com> X-Mailer: git-send-email 2.33.0 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 Thanks for your reply! > default slice = 0.75 msec * (1 + ilog(ncpus)) with ncpus capped at 8 > which means that we have a default slice of > 0.75 for 1 cpu > 1.50 up to 3 cpus > 2.25 up to 7 cpus > 3.00 for 8 cpus and above > > For HZ=250 and HZ=100, all values are "ok". By "ok", I mean that task > will not get an extra tick but their runtime remains far higher than > their slice. The only config that has an issue is HZ=1000 with 8 cpus > or more. > > Using 0.70 instead of 0.75 should not change much for other configs > and would fix this config too with a default slice equals 2.8ms. > 0.70 for 1 cpu > 1.40 up to 3 cpus > 2.10 up to 7 cpus > 2.8 for 8 cpus and above It seems that changing the default slice is a good idea that won't have too much impact and solves the main problem. I strongly agree with it, which is more reasonable than the forward deadline. > That being said the problem remains the same if a task sets its custom > slice being a multiple of ticks or the time stolen by interrupts is > higher than 66us per tick in average Additionally, can we add some warnings on this basis? We do not prevent slices from being integer multiples of the tick, but we do not recommend doing it. Here is the patch I have written based on the above logic, looking forward to your feedback. Signed-off-by: zihan zhou <15645113830zzh@gmail.com> --- kernel/sched/debug.c | 48 ++++++++++++++++++++++++++++++++++++++++- kernel/sched/fair.c | 6 +++--- kernel/sched/syscalls.c | 4 ++++ 3 files changed, 54 insertions(+), 4 deletions(-) diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c index a1be00a988bf..da17d19082ba 100644 --- a/kernel/sched/debug.c +++ b/kernel/sched/debug.c @@ -166,6 +166,52 @@ static const struct file_operations sched_feat_fops = { .release = single_release, }; + +static ssize_t sched_base_slice_write(struct file *filp, const char __user *ubuf, + size_t cnt, loff_t *ppos) +{ + char buf[16]; + unsigned int base_slice; + + if (cnt > 15) + cnt = 15; + + if (copy_from_user(&buf, ubuf, cnt)) + return -EFAULT; + buf[cnt] = '\0'; + + if (kstrtouint(buf, 10, &base_slice)) + return -EINVAL; + + + sysctl_sched_base_slice = base_slice; + + if (sysctl_sched_base_slice % TICK_NSEC == 0) + pr_warn("It is not recommended to set the slice to an integer multiple of the tick\n"); + + *ppos += cnt; + return cnt; +} + +static int sched_base_slice_show(struct seq_file *m, void *v) +{ + seq_printf(m, "%d\n", sysctl_sched_base_slice); + return 0; +} + +static int sched_base_slice_open(struct inode *inode, struct file *filp) +{ + return single_open(filp, sched_base_slice_show, NULL); +} + +static const struct file_operations sched_base_slice_fops = { + .open = sched_base_slice_open, + .write = sched_base_slice_write, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + #ifdef CONFIG_SMP static ssize_t sched_scaling_write(struct file *filp, const char __user *ubuf, @@ -505,7 +551,7 @@ static __init int sched_init_debug(void) debugfs_create_file("preempt", 0644, debugfs_sched, NULL, &sched_dynamic_fops); #endif - debugfs_create_u32("base_slice_ns", 0644, debugfs_sched, &sysctl_sched_base_slice); + debugfs_create_file("base_slice_ns", 0644, debugfs_sched, NULL, &sched_base_slice_fops); debugfs_create_u32("latency_warn_ms", 0644, debugfs_sched, &sysctl_resched_latency_warn_ms); debugfs_create_u32("latency_warn_once", 0644, debugfs_sched, &sysctl_resched_latency_warn_once); diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 3e9ca38512de..27f7cf205741 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -71,10 +71,10 @@ unsigned int sysctl_sched_tunable_scaling = SCHED_TUNABLESCALING_LOG; /* * Minimal preemption granularity for CPU-bound tasks: * - * (default: 0.75 msec * (1 + ilog(ncpus)), units: nanoseconds) + * (default: 0.70 msec * (1 + ilog(ncpus)), units: nanoseconds) */ -unsigned int sysctl_sched_base_slice = 750000ULL; -static unsigned int normalized_sysctl_sched_base_slice = 750000ULL; +unsigned int sysctl_sched_base_slice = 700000ULL; +static unsigned int normalized_sysctl_sched_base_slice = 700000ULL; const_debug unsigned int sysctl_sched_migration_cost = 500000UL; diff --git a/kernel/sched/syscalls.c b/kernel/sched/syscalls.c index ff0e5ab4e37c..d0f90d61398f 100644 --- a/kernel/sched/syscalls.c +++ b/kernel/sched/syscalls.c @@ -309,6 +309,10 @@ static void __setscheduler_params(struct task_struct *p, p->se.slice = clamp_t(u64, attr->sched_runtime, NSEC_PER_MSEC/10, /* HZ=1000 * 10 */ NSEC_PER_MSEC*100); /* HZ=100 / 10 */ + + if (p->se.slice % TICK_NSEC == 0) + pr_warn("It is not recommended to set the slice to an integer multiple of the tick\n"); + } else { p->se.custom_slice = 0; p->se.slice = sysctl_sched_base_slice; -- 2.33.0