[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_1A4C28B62DA5726C31A985601B07F664250A@qq.com>
Date: Tue, 25 Feb 2025 23:35:12 +0800
From: Chen Yu <yu.chen.surf@...mail.com>
To: Qais Yousef <qyousef@...alina.io>
Cc: Peter Zijlstra <peterz@...radead.org>,
zihan zhou <15645113830zzh@...il.com>, oe-lkp@...ts.linux.dev,
kernel test robot <oliver.sang@...el.com>, lkp@...el.com,
linux-kernel@...r.kernel.org, x86@...nel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
aubrey.li@...ux.intel.com, yu.c.chen@...el.com
Subject: Re: [tip:sched/core] [sched] 2ae891b826: hackbench.throughput 6.2%
regression
On 2025-02-25 at 13:42:20 +0000, Qais Yousef wrote:
> On 02/25/25 21:15, Chen Yu wrote:
> > On 2025-02-25 at 13:27:05 +0100, Peter Zijlstra wrote:
> > > On Tue, Feb 25, 2025 at 05:31:34PM +0800, Chen Yu wrote:
> > >
> > > >
> > > > But consider that the 6% regression is not that high, and the user might customize
> > > > base_slice via debugfs on-demand, we can keep an eye on this and revist it in the
> > > > future(we have encountered some SPECjbb regression due to over-preemption).
> > >
> > > You can specify a per-task slice using sched_attr::sched_runtime. Also
> > > see commit 857b158dc5e8 ("sched/eevdf: Use sched_attr::sched_runtime to
> > > set request/slice suggestion")
> > >
> > >
> >
> > Thanks, we'll have a try during the next test cycle.
>
> Could you also try with HRTICK enabled?
>
> echo HRTICK | sudo tee /sys/kernel/debug/sched/features
Sure. Is HRTICK supposed to encourage preemption? I thought
hackbench might be sensitive to preemption(downgrading).
thanks,
Chenyu
Powered by blists - more mailing lists