Hello, guys.
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
I guess this could be one use of 'reordering' after a requeue.
Yeah, or perhaps the io scheduler might determine that a request has
higher prio than a requeued one.
On Wed, Apr 20 2005, Nick Piggin wrote:
> Jens Axboe wrote:
> >On Wed, Apr 20 2005, Nick Piggin wrote:
> >
>
> >>I guess this could be one use of 'reordering' after a requeue.
> >
> >
> >Yeah, or perhaps the io scheduler might determine that a request has
> >higher prio than a requeued one. I'm
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
I guess this could be one use of 'reordering' after a requeue.
Yeah, or perhaps the io scheduler might determine that a request has
higher prio than a requeued one. I'm not sure what semantics to place
I guess this is possible. It is
On Wed, Apr 20 2005, Nick Piggin wrote:
> >>Hmm, well, it seems that setting REQ_SOFTBARRIER on requeue path isn't
> >>necessary as we have INSERT_FRONT policy on requeue, and if
> >>elv_next_req_fn() is required to return the same request when the
> >>request isn't dequeued, you're right and we
Jens Axboe wrote:
On Wed, Apr 20 2005, Tejun Heo wrote:
Well, yeah, all schedulers have dispatch queue (noop has only the
dispatch queue) and use them to defer/requeue, so no reordering will
happen, but I'm not sure they are required to be like this or just
happen to be implemented so.
On Wed, Apr 20 2005, Tejun Heo wrote:
> Nick Piggin wrote:
> > On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
> >
> >> Hello, Jens.
> >>
> >>On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
> >>
> >>>Do it on requeue, please - not on the initial spotting of the request.
> >>
> >>
Nick Piggin wrote:
> On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
>
>> Hello, Jens.
>>
>>On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
>>
>>>Do it on requeue, please - not on the initial spotting of the request.
>>
>> This is the reworked version of the patch. It sets
On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
> Hello, Jens.
>
> On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
> > Do it on requeue, please - not on the initial spotting of the request.
>
> This is the reworked version of the patch. It sets REQ_SOFTBARRIER
> in two places
Hello, Jens.
On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
> Do it on requeue, please - not on the initial spotting of the request.
This is the reworked version of the patch. It sets REQ_SOFTBARRIER
in two places - in elv_next_request() on BLKPREP_DEFER and in
Jens Axboe wrote:
On Wed, Apr 20 2005, Tejun Heo wrote:
01_scsi_blk_make_started_requests_ordered.patch
Reordering already started requests is without any real
benefit and causes problems if the request has its
driver-specific resources allocated (as in SCSI). This patch
On Wed, Apr 20 2005, Tejun Heo wrote:
> 01_scsi_blk_make_started_requests_ordered.patch
>
> Reordering already started requests is without any real
> benefit and causes problems if the request has its
> driver-specific resources allocated (as in SCSI). This patch
> makes
On Wed, Apr 20 2005, Tejun Heo wrote:
01_scsi_blk_make_started_requests_ordered.patch
Reordering already started requests is without any real
benefit and causes problems if the request has its
driver-specific resources allocated (as in SCSI). This patch
makes
Jens Axboe wrote:
On Wed, Apr 20 2005, Tejun Heo wrote:
01_scsi_blk_make_started_requests_ordered.patch
Reordering already started requests is without any real
benefit and causes problems if the request has its
driver-specific resources allocated (as in SCSI). This patch
Hello, Jens.
On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
Do it on requeue, please - not on the initial spotting of the request.
This is the reworked version of the patch. It sets REQ_SOFTBARRIER
in two places - in elv_next_request() on BLKPREP_DEFER and in
On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
Hello, Jens.
On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
Do it on requeue, please - not on the initial spotting of the request.
This is the reworked version of the patch. It sets REQ_SOFTBARRIER
in two places - in
Nick Piggin wrote:
On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
Hello, Jens.
On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
Do it on requeue, please - not on the initial spotting of the request.
This is the reworked version of the patch. It sets REQ_SOFTBARRIER
in two
On Wed, Apr 20 2005, Tejun Heo wrote:
Nick Piggin wrote:
On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
Hello, Jens.
On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
Do it on requeue, please - not on the initial spotting of the request.
This is the reworked
Jens Axboe wrote:
On Wed, Apr 20 2005, Tejun Heo wrote:
Well, yeah, all schedulers have dispatch queue (noop has only the
dispatch queue) and use them to defer/requeue, so no reordering will
happen, but I'm not sure they are required to be like this or just
happen to be implemented so.
On Wed, Apr 20 2005, Nick Piggin wrote:
Hmm, well, it seems that setting REQ_SOFTBARRIER on requeue path isn't
necessary as we have INSERT_FRONT policy on requeue, and if
elv_next_req_fn() is required to return the same request when the
request isn't dequeued, you're right and we don't need
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
I guess this could be one use of 'reordering' after a requeue.
Yeah, or perhaps the io scheduler might determine that a request has
higher prio than a requeued one. I'm not sure what semantics to place
I guess this is possible. It is
On Wed, Apr 20 2005, Nick Piggin wrote:
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
I guess this could be one use of 'reordering' after a requeue.
Yeah, or perhaps the io scheduler might determine that a request has
higher prio than a requeued one. I'm not sure what
Hello, guys.
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
Jens Axboe wrote:
On Wed, Apr 20 2005, Nick Piggin wrote:
I guess this could be one use of 'reordering' after a requeue.
Yeah, or perhaps the io scheduler might determine that a request has
higher prio than a requeued one.
01_scsi_blk_make_started_requests_ordered.patch
Reordering already started requests is without any real
benefit and causes problems if the request has its
driver-specific resources allocated (as in SCSI). This patch
makes elv_next_request() set REQ_SOFTBARRIER
01_scsi_blk_make_started_requests_ordered.patch
Reordering already started requests is without any real
benefit and causes problems if the request has its
driver-specific resources allocated (as in SCSI). This patch
makes elv_next_request() set REQ_SOFTBARRIER
24 matches
Mail list logo
