[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200828090729.GT1362448@hirez.programming.kicks-ass.net>
Date: Fri, 28 Aug 2020 11:07:29 +0200
From: peterz@...radead.org
To: Xianting Tian <tian.xianting@....com>
Cc: <viro@...iv.linux.org.uk>, <bcrl@...ck.org>, <mingo@...hat.com>,
<juri.lelli@...hat.com>, <vincent.guittot@...aro.org>,
<dietmar.eggemann@....com>, <rostedt@...dmis.org>,
<bsegall@...gle.com>, <mgorman@...e.de>, <jack@...e.cz>,
<linux-fsdevel@...r.kernel.org>, <linux-aio@...ck.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] aio: make aio wait path to account iowait time
On Fri, Aug 28, 2020 at 02:07:12PM +0800, Xianting Tian wrote:
> As the normal aio wait path(read_events() ->
> wait_event_interruptible_hrtimeout()) doesn't account iowait time, so use
> this patch to make it to account iowait time, which can truely reflect
> the system io situation when using a tool like 'top'.
Do be aware though that io_schedule() is potentially far more expensive
than regular schedule() and io-wait accounting as a whole is a
trainwreck.
When in_iowait is set schedule() and ttwu() will have to do additional
atomic ops, and (much) worse, PSI will take additional locks.
And all that for a number that, IMO, is mostly useless, see the comment
with nr_iowait().
But, if you don't care about performance, and want to see a shiny random
number generator, by all means, use io_schedule().
Powered by blists - more mailing lists