[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4A5DA461.5010401@kernel.org>
Date: Wed, 15 Jul 2009 18:41:53 +0900
From: Tejun Heo <tj@...nel.org>
To: Boaz Harrosh <bharrosh@...asas.com>
CC: Jens Axboe <jens.axboe@...cle.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
James Bottomley <James.Bottomley@...senPartnership.com>,
linux-scsi <linux-scsi@...r.kernel.org>,
Niel Lambrechts <niel.lambrechts@...il.com>,
FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
Jens Axboe <axboe@...nel.dk>
Subject: Re: [PATCH 3/4] block: implement mixed merge of different failfast
requests
Boaz Harrosh wrote:
> On 07/09/2009 03:47 AM, Tejun Heo wrote:
>> Hello,
>>
>> Boaz Harrosh wrote:
>>>> @@ -1165,6 +1165,7 @@ static int __make_request(struct request_queue *q, struct bio *bio)
>>>> const unsigned short prio = bio_prio(bio);
>>>> const int sync = bio_sync(bio);
>>>> const int unplug = bio_unplug(bio);
>>>> + const unsigned int ff = bio->bi_rw & REQ_FAILFAST_MASK;
>>> Perhaps a bio_fail_fast(bio)
>>> and also an blk_failfast(rq).
>> Me not being a big fan of those simple accessors, I want to avoid
>> adding those especially the use of bio ones are mostly confined to
>> block layer proper.
>>
>
> OK but at least take care of blk_noretry_request(), at the minimum
> kill it, and use req->cmd_flags & REQ_FAILFAST_MASK everywhere.
Hmmm... looking at it now, looks like we can kill them all actually.
There are a lot of inconsistencies in this space.
* BIO_RW_* are bit positions and accessed with liberal combination of
bio_rw_flagged() and manual bitops.
* QUEUE_FLAG_* are bit positions and has rather large collection of
accessors. The accessors have locking asserts.
* __REQ_* are bit positions but have counter part REQ_* bit masks
defined and there are whole bunch of simple specific accessors.
I think all these can just be converted to bit masks (and I'll be
happy with that) but whether that would be desirable is a different
matter. I think it would be best to hear what Jens' plan about flag
cleanup is (who BTW is away till the end of the next week) before
proceeding.
Jens, can you please let us know what your plan is?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists