"Jens Axboe wrote:"
> [ptb wrote]
> > through merge_reqeusts function controls.
> > My unease derives, I think, from the fact that I have occasionally used
> > plugging for other purposes. Namely for throttling the device. These
> > uses have always been experimental and uniformly unsuccessful,
On Thu, Apr 19 2001, Peter T. Breuer wrote:
> OK - agreed. But while I have your attention...
>
> "Jens Axboe wrote:"
> > On the contrary, you are now given an exceptional opportunity to clean
> > up your code and get rid of blk_queue_pluggable and your noop plugging
> > function.
>
> In
OK - agreed. But while I have your attention...
"Jens Axboe wrote:"
> On the contrary, you are now given an exceptional opportunity to clean
> up your code and get rid of blk_queue_pluggable and your noop plugging
> function.
In summary: blk_queue_pluggable can be removed for all driver codes
On Thu, Apr 19 2001, Peter T. Breuer wrote:
> "Jens Axboe wrote:"
> > Examine _why_ you don't want plugging. In 2.2, you would have to edit
> > the kernel manually to disable it for your device.
>
> True. Except that I borrowed a major which already got that special
> treatment.
Ok
> >
"Jens Axboe wrote:"
> Examine _why_ you don't want plugging. In 2.2, you would have to edit
> the kernel manually to disable it for your device.
True. Except that I borrowed a major which already got that special
treatment.
>For 2.4, as long as
>
On Thu, Apr 19 2001, Peter T. Breuer wrote:
> "A month of sundays ago Jens Axboe wrote:"
> > On Thu, Apr 19 2001, Peter T. Breuer wrote:
> > > So the consensus is that I should enable plugging while the plugging
> > > function is still here and do nothing when it goes? I must say I don't
> > >
"A month of sundays ago Jens Axboe wrote:"
> On Thu, Apr 19 2001, Peter T. Breuer wrote:
> > So the consensus is that I should enable plugging while the plugging
> > function is still here and do nothing when it goes? I must say I don't
> > think it should really "go", since that means I have to
On Thu, Apr 19 2001, Peter T. Breuer wrote:
> > Besides, the above hunk was removed because it is wrong. For devices
> > using plugging, we would re-call the request_fn while the device was
> > already active and serving requests. Not only is this a performance hit
>
> Not sure about that ...
OK .. thanks Jens. Sorry about the repeat .. my nameserver lost its fix
on the root servers thanks to some hurried upgrades, and sendmail
started quietly bouncing mail for "not having" a dns entry, and you
know about deja. Probably the list dropped me for the bounces.
Those are my excuses.
On Thu, Apr 19 2001, Peter T. Breuer wrote:
> Sorry to repeat .. I didn't see this go out on the list and I haven't
> had any reply. So let's ask again. Is this a new coding error in ll_rw_blk?
>
> -
>
> The following has been lost from __make_request() in ll_rw_blk.c since
>
Sorry to repeat .. I didn't see this go out on the list and I haven't
had any reply. So let's ask again. Is this a new coding error in ll_rw_blk?
-
The following has been lost from __make_request() in ll_rw_blk.c since
2.4.2 (incl):
out:
- if (!q->plugged)
-
Sorry to repeat .. I didn't see this go out on the list and I haven't
had any reply. So let's ask again. Is this a new coding error in ll_rw_blk?
-
The following has been lost from __make_request() in ll_rw_blk.c since
2.4.2 (incl):
out:
- if (!q-plugged)
-
On Thu, Apr 19 2001, Peter T. Breuer wrote:
Sorry to repeat .. I didn't see this go out on the list and I haven't
had any reply. So let's ask again. Is this a new coding error in ll_rw_blk?
-
The following has been lost from __make_request() in ll_rw_blk.c since
2.4.2
OK .. thanks Jens. Sorry about the repeat .. my nameserver lost its fix
on the root servers thanks to some hurried upgrades, and sendmail
started quietly bouncing mail for "not having" a dns entry, and you
know about deja. Probably the list dropped me for the bounces.
Those are my excuses.
On Thu, Apr 19 2001, Peter T. Breuer wrote:
Besides, the above hunk was removed because it is wrong. For devices
using plugging, we would re-call the request_fn while the device was
already active and serving requests. Not only is this a performance hit
Not sure about that ...
It _is_
"A month of sundays ago Jens Axboe wrote:"
On Thu, Apr 19 2001, Peter T. Breuer wrote:
So the consensus is that I should enable plugging while the plugging
function is still here and do nothing when it goes? I must say I don't
think it should really "go", since that means I have to add a
"Jens Axboe wrote:"
Examine _why_ you don't want plugging. In 2.2, you would have to edit
the kernel manually to disable it for your device.
True. Except that I borrowed a major which already got that special
treatment.
For 2.4, as long as
there
On Thu, Apr 19 2001, Peter T. Breuer wrote:
"Jens Axboe wrote:"
Examine _why_ you don't want plugging. In 2.2, you would have to edit
the kernel manually to disable it for your device.
True. Except that I borrowed a major which already got that special
treatment.
Ok
OK - agreed. But while I have your attention...
"Jens Axboe wrote:"
On the contrary, you are now given an exceptional opportunity to clean
up your code and get rid of blk_queue_pluggable and your noop plugging
function.
In summary: blk_queue_pluggable can be removed for all driver codes
On Thu, Apr 19 2001, Peter T. Breuer wrote:
OK - agreed. But while I have your attention...
"Jens Axboe wrote:"
On the contrary, you are now given an exceptional opportunity to clean
up your code and get rid of blk_queue_pluggable and your noop plugging
function.
In summary:
"Jens Axboe wrote:"
[ptb wrote]
through merge_reqeusts function controls.
My unease derives, I think, from the fact that I have occasionally used
plugging for other purposes. Namely for throttling the device. These
uses have always been experimental and uniformly unsuccessful, because
On Tue, Apr 17 2001, Peter T. Breuer wrote:
> Well, anyway, as far as I can tell, the following has been lost from
> __make_request() in ll_rw_blk.c since the 2.4.0 days:
>
> out:
> - if (!q->plugged)
> - (q->request_fn)(q);
> if (freereq)
>
> The result appears to
Well, anyway, as far as I can tell, the following has been lost from
__make_request() in ll_rw_blk.c since the 2.4.0 days:
out:
- if (!q->plugged)
- (q->request_fn)(q);
if (freereq)
The result appears to be that if a block device has called
blk_queue_pluggable() to
Well, anyway, as far as I can tell, the following has been lost from
__make_request() in ll_rw_blk.c since the 2.4.0 days:
out:
- if (!q-plugged)
- (q-request_fn)(q);
if (freereq)
The result appears to be that if a block device has called
blk_queue_pluggable() to
On Tue, Apr 17 2001, Peter T. Breuer wrote:
Well, anyway, as far as I can tell, the following has been lost from
__make_request() in ll_rw_blk.c since the 2.4.0 days:
out:
- if (!q-plugged)
- (q-request_fn)(q);
if (freereq)
The result appears to be that if
25 matches
Mail list logo
