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: <d6658b60b7e09376cfcf692dc54ac922.squirrel@www.codeaurora.org>
Date:	Wed, 27 Mar 2013 12:09:41 -0700
From:	tlinder@...eaurora.org
To:	"Jens Axboe" <axboe@...nel.dk>
Cc:	"Tanya Brokhman" <tlinder@...eaurora.org>,
	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

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.

> So why this
> duplication? I also don't quite understand why an IO scheduler would
> have to opt-in for this, seems like a pretty basic operation.

I hope the above example addressed this as well. Please let me know if
this is not the case.

Thanks
Tanya Brokhman
QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation



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