All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Bart Van Assche <bvanassche@acm.org>,
	gumi@linux.alibaba.com, damien.lemoal@opensource.wdc.com
Cc: linux-block@vger.kernel.org
Subject: Re: [PATCH v2] block: I/O error occurs during SATA disk stress test
Date: Fri, 26 Aug 2022 13:40:54 -0600	[thread overview]
Message-ID: <07dbb2ac-04ea-d09c-9e46-8d77bcedbb93@kernel.dk> (raw)
In-Reply-To: <f95bf278-e999-2068-01bd-c01f363e66a5@acm.org>

On 8/26/22 10:06 AM, Bart Van Assche wrote:
> On 8/26/22 06:36, Jens Axboe wrote:
>> That aside, I think there's a misunderstanding here. v1 has some
>> parts and v2 has others. Please post a v3 that has the hunk
>> that guarantees that deadline always has the lowest bit set if
>> assigned, and the !deadline check as well.
> 
> Hi Jens,
> 
> Would it be considered acceptable to store the request state
> (rq->state) in the lowest two bits of rq->deadline? This would reduce
> the deadline resolution a little bit but I think that's acceptable.
> Except for blk_abort_request(), all changes of rq->state and
> rq->deadline are already serialized. So with this approach only
> blk_abort_request() would have to use an atomic-compare-exchange loop.

Sure, I think that would be fine, as long as:

1) We keep the expensive bits in the actual timeout/abort path and not
   part of regular issue.

2) We rename the field while doing so.

Might even be worthwhile to look into NOT having both timeout and
deadline in struct request, it's a bit annoying to waste double the
space on something that should just be one field.

-- 
Jens Axboe

  reply	other threads:[~2022-08-26 19:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26  3:25 [PATCH v2] block: I/O error occurs during SATA disk stress test gumi
2022-08-26 13:36 ` Jens Axboe
2022-08-26 16:06   ` Bart Van Assche
2022-08-26 19:40     ` Jens Axboe [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-08-29  4:11 gumi
2022-08-29  4:07 gumi
2022-08-29  3:25 gumi
2022-08-29  3:30 ` Bart Van Assche
2022-08-25  7:09 Gu Mi
2022-08-25 17:18 ` Bart Van Assche
2022-08-26 21:15 ` Bart Van Assche

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=07dbb2ac-04ea-d09c-9e46-8d77bcedbb93@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=gumi@linux.alibaba.com \
    --cc=linux-block@vger.kernel.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 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.