[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdR0DtDCWWFkSiUn@infradead.org>
Date: Tue, 20 Feb 2024 01:42:38 -0800
From: Christoph Hellwig <hch@...radead.org>
To: "zhaoyang.huang" <zhaoyang.huang@...soc.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
linux-kernel@...r.kernel.org,
Zhaoyang Huang <huangzhaoyang@...il.com>, steve.kang@...soc.com
Subject: Re: [PATCH 2/2] block: adjust CFS request expire time
On Tue, Feb 20, 2024 at 02:15:42PM +0800, zhaoyang.huang wrote:
> From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
>
> According to current policy, CFS's may suffer involuntary IO-latency by
> being preempted by RT/DL tasks or IRQ since they possess the privilege for
> both of CPU and IO scheduler.
What is 'current policy', what is CFS, what is RT/DL? What privilege
is possessed?
> 1. All types of sched class's load(util) are tracked and calculated in the
> same way(using a geometric series which known as PELT)
> 2. Keep the legacy policy by NOT adjusting rq's position in fifo_list
> but only make changes over expire_time.
> 3. The fixed expire time(hundreds of ms) is in the same range of cpu
> avg_load's account series(the utilization will be decayed to 0.5 in 32ms)
What problem does this fix, i.e. what performance number are improved
or what other effects does it have?
> + * The expire time is adjusted via calculating the proportion of
> + * CFS's activation among whole cpu time during last several
> + * dazen's ms.Whearas, this would NOT affect the rq's position in
> + * fifo_list but only take effect when this rq is checked for its
> + * expire time when at head.
> */
Please speel check the comment and fix the formatting to have white
spaces after sentences and never exceed 80 characters in block comments.
Powered by blists - more mailing lists