From: Tejun Heo <tj@kernel.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Jakub Kicinski <kuba@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Johannes Thumshirn <johannes.thumshirn@wdc.com>,
davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, pabeni@redhat.com,
bpf@vger.kernel.org
Subject: Re: [GIT PULL] Networking for v6.9
Date: Tue, 12 Mar 2024 12:14:30 -1000 [thread overview]
Message-ID: <ZfDTxhn34fihYQ_o@slm.duckdns.org> (raw)
In-Reply-To: <fee2fccf-ef4d-4595-8f20-07ba4dc67d42@kernel.dk>
Hello,
On Tue, Mar 12, 2024 at 04:02:08PM -0600, Jens Axboe wrote:
> diff --git a/block/blk.h b/block/blk.h
> index a19b7b42e650..5cac4e29ae17 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -534,7 +534,7 @@ static inline u64 blk_time_get_ns(void)
> {
> struct blk_plug *plug = current->plug;
>
> - if (!plug)
> + if (!plug || !in_task())
> return ktime_get_ns();
Late to the party but I think the following is what iocost is doing:
1. A cgroup overspends and needs to wait before issuing further IOs. It
takes the current time, add the duratoin that it'd need to wait to issue
further IOs and then schedules the hrtimer.
2. The timer triggers and runs iocg_waitq_timer_fn() which takes the current
time and calculates its current budget (which gets replenished as time
passes). If the pending IOs fit in the current budget, it issues them. If
there are still pending IOs, it calculates the next timer wakeup point as
the read current time + the time needed to resume IO processing.
3. If the read current time is sufficiently in the past, the hrtimer
scheduled in #2 would expire immediately and if it still reads the same
cached current time, the calculated budget would be zero. It won't be
able to issue any more IOs and will schedule the hrtimer on the same
exact expire time as before, falling into an infinite loop.
So, whatever that can feed actual time to iocg_wait_timer_fn() should fix
the issue.
Thanks.
--
tejun
next prev parent reply other threads:[~2024-03-12 22:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 4:25 [GIT PULL] Networking for v6.9 Jakub Kicinski
2024-03-12 20:17 ` Linus Torvalds
2024-03-12 20:34 ` Jakub Kicinski
2024-03-12 20:47 ` Jakub Kicinski
2024-03-12 21:11 ` Linus Torvalds
2024-03-12 21:40 ` Jens Axboe
2024-03-12 21:48 ` Jakub Kicinski
2024-03-12 21:53 ` Jens Axboe
2024-03-12 21:55 ` Jakub Kicinski
2024-03-12 22:02 ` Jens Axboe
2024-03-12 22:14 ` Tejun Heo [this message]
2024-03-12 22:24 ` Jakub Kicinski
2024-03-13 0:00 ` Jakub Kicinski
2024-03-13 1:00 ` Linus Torvalds
2024-03-13 1:10 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZfDTxhn34fihYQ_o@slm.duckdns.org \
--to=tj@kernel.org \
--cc=axboe@kernel.dk \
--cc=bpf@vger.kernel.org \
--cc=davem@davemloft.net \
--cc=johannes.thumshirn@wdc.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox