From: Uday Shankar <ushankar@purestorage.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Costa Sapuntzakis <costa@purestorage.com>,
Randy Jennings <randyj@purestorage.com>,
Hannes Reinecke <hare@suse.de>, Sagi Grimberg <sagi@grimberg.me>,
Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@fb.com>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH v3 2/3] nvme: check IO start time when deciding to defer KA
Date: Wed, 24 May 2023 13:53:00 -0600 [thread overview]
Message-ID: <20230524195300.GA1361172@dev-ushankar.dev.purestorage.com> (raw)
In-Reply-To: <20230520043422.GE31780@lst.de>
On Sat, May 20, 2023 at 06:34:22AM +0200, Christoph Hellwig wrote:
> I also can't really see a reason for the barrier here
In this version of the patch, I have this bit in nvme_complete_rq:
+ if (ctrl->kas && !ctrl->comp_seen &&
+ nvme_req(req)->start_time >= ctrl->ka_last_check_time)
and the code that updates ka_last_check_time looks like this:
+ WRITE_ONCE(ctrl->ka_last_check_time, jiffies);
+ smp_wmb();
ctrl->comp_seen = false;
I used WRITE_ONCE and smp_wmb here to try to avoid reordering of writes
here, as I didn't want nvme_complete_rq to be able to observe comp_seen
as false while ka_last_check_time still has its pre-update value. I
agree if I wanted to do this properly, I need to add a smb_rmb and
READ_ONCE(ka_last_check_time) in nvme_complete_rq.
However, the read of comp_seen here is a (probably premature) attempt at
optimization, which may well be completely unnoticeable. I removed it in
v4, and as a result the READ/WRITE_ONCE and barriers are no longer
needed.
next prev parent reply other threads:[~2023-05-24 19:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-18 18:33 [PATCH v3 0/3] keepalive bugfixes Uday Shankar
2023-05-18 18:33 ` [PATCH v3 1/3] nvme: double KA polling frequency to avoid KATO with TBKAS on Uday Shankar
2023-05-20 4:28 ` Christoph Hellwig
2023-05-18 18:33 ` [PATCH v3 2/3] nvme: check IO start time when deciding to defer KA Uday Shankar
2023-05-20 4:34 ` Christoph Hellwig
2023-05-24 19:53 ` Uday Shankar [this message]
2023-05-18 18:33 ` [PATCH v3 3/3] nvme: improve handling of long keep alives Uday Shankar
2023-05-20 4:36 ` Christoph Hellwig
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=20230524195300.GA1361172@dev-ushankar.dev.purestorage.com \
--to=ushankar@purestorage.com \
--cc=axboe@fb.com \
--cc=costa@purestorage.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=randyj@purestorage.com \
--cc=sagi@grimberg.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.