linux-kernel - Re: [PATCH v5 1/3] block: Add support for reinsert a dispatched req

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130328184922.GE19488@kernel.dk>
Date:	Thu, 28 Mar 2013 12:49:22 -0600
From:	Jens Axboe <axboe@...nel.dk>
To:	tlinder@...eaurora.org
Cc:	linux-mmc@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	alex.lemberg@...disk.com, open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 1/3] block: Add support for reinsert a dispatched req

On Wed, Mar 27 2013, tlinder@...eaurora.org wrote:
> Hi Jens
> 
> >> Add support for reinserting a dispatched request back to the
> >> scheduler's internal data structures.
> >> This capability is used by the device driver when it chooses to
> >> interrupt the current request transmission and execute another (more
> >> urgent) pending request. For example: interrupting long write in order
> >> to handle pending read. The device driver re-inserts the
> >> remaining write request back to the scheduler, to be rescheduled
> >> for transmission later on.
> >>
> >> Add API for verifying whether the current scheduler
> >> supports reinserting requests mechanism. If reinsert mechanism isn't
> >> supported by the scheduler, this code path will never be activated.
> >
> > This is practically the exact same operation as a requeue.
> 
> Not exactly. When you requeue request X it will be the next one to be
> dispatched and handled by the device driver. When you reinsert a request,
> you reinset it back to the I/O scheduler and not to the dispatch queue.
> That means that this reinserted request will be rescheduled and its
> possible that it wont be the next one to be dispatched since there might
> be more urgent requests pending.
> For example: an urgent request notification was sent to the device driver
> that is currently transmitting a long packed WRITE command. The urgent
> request pending to be served is a READ request. The device driver decides
> to stop the packed WRITE request and handle the urgent READ. This is the
> difference between requeue and reinsert:
>  - if we requeue the stopped packed WRITE, it will be immediately fetched
> and transmitted again and the READ will be left pending till the packed
> WRITE completes. In this case there was no point in stopping the packed
> WRITE
> - if we reinsert the stopped packed WRITE the next request to be
> dispatched will be the urgent READ request (since READ is given priority
> over WRITE) and this will reduce the READ latency greatly.

I said practically the same, not exactly the same! In any case, the
point is that you could reuse the exact same infrastructure for this,
instead of literally duplicating everything. Have some helper that does
the grunt of the work, pass in whether or not you want the existing
requeue event, or a reinsert event.

-- 
Jens Axboe

--
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/