On Mon, Jan 15 2007, Linas Vepstas wrote:
>
> Hi Chris, Jens,
> Can you look at this, and push upstream if this looks reasonable
> to you? It fixes a bug I've been tripping over.
>
> --linas
>
>
> A flag was recently added to the elevator code to avoid
> per
Hi Chris, Jens,
Can you look at this, and push upstream if this looks reasonable
to you? It fixes a bug I've been tripping over.
--linas
A flag was recently added to the elevator code to avoid
performing an unplug when reuests are being re-queued.
The goal of this flag was to avoid a deep
Hi Chris, Jens,
Can you look at this, and push upstream if this looks reasonable
to you? It fixes a bug I've been tripping over.
--linas
A flag was recently added to the elevator code to avoid
performing an unplug when reuests are being re-queued.
The goal of this flag was to avoid a deep
On Mon, Jan 15 2007, Linas Vepstas wrote:
Hi Chris, Jens,
Can you look at this, and push upstream if this looks reasonable
to you? It fixes a bug I've been tripping over.
--linas
A flag was recently added to the elevator code to avoid
performing an unplug when reuests are being re
03_blk_generic-last_merge-handling.patch
Currently, both generic elevator code and specific ioscheds
participate in the management and usage of last_merge. This
and the following patches move last_merge handling into
generic elevator code.
Signed-off-by: Tejun
03_blk_generic-last_merge-handling.patch
Currently, both generic elevator code and specific ioscheds
participate in the management and usage of last_merge. This
and the following patches move last_merge handling into
generic elevator code.
Signed-off-by: Tejun
On Wed, Sep 13, 2000 at 03:08:27PM -0400, Horst von Brand wrote:
> "Jeff V. Merkey" <[EMAIL PROTECTED]> said:
>
> [...]
>
> > I have concluded that Linux will only progress as fast as Linus does.
> > Linux has forked twice now, and the new variants are not named "Linux"
> > anymore, so these
On Thu, Sep 14, 2000 at 04:00:31PM +0200, Andrea Arcangeli wrote:
> On Wed, 13 Sep 2000, Andi Kleen wrote:
>
> >I guess it boils down to that the plugging (run_task(_disc)) is overloaded
> >in Linux. It does merging of requests which are the same anyways (=from the
> >same operation in upper
On Wed, 13 Sep 2000, Andi Kleen wrote:
>I guess it boils down to that the plugging (run_task(_disc)) is overloaded
>in Linux. It does merging of requests which are the same anyways (=from the
>same operation in upper layers) and merging of requests that are unrelated.
_disk doesn't merge
On Wed, 13 Sep 2000, Andi Kleen wrote:
I guess it boils down to that the plugging (run_task(tq_disc)) is overloaded
in Linux. It does merging of requests which are the same anyways (=from the
same operation in upper layers) and merging of requests that are unrelated.
tq_disk doesn't merge
"Jeff V. Merkey" <[EMAIL PROTECTED]> said:
[...]
> I have concluded that Linux will only progress as fast as Linus does. Linux
> has forked twice now, and the new variants are not named "Linux" anymore, so
> these types of changes may occur more quickly since there will be independent
>
Andi Kleen wrote:
>
> On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote:
> > About B) I can' believe you seriously want to duplicate the merging code
> > in each lowlevel driver given most of them could share the same code (as
> > they're doing in linux).
>
> I guess it would
On Wed, 13 Sep 2000, Martin Dalecki wrote:
>Yes seriously I would like to see it duplicated there. Becouse on this
>level it would be *far* simpler then on the generic level. And for
What do you mean with "simpler".
>a noabnormal configuration I guess the overall code size would
>be smaller
Hans Reiser wrote:
>
> If you modify this to only be invoked when starvation of is detected, that is, to
>only prevent
> filling the removing queue when the oldest unsatisfied request exceeds some tunable
>age, then I like
> the model for those situations where real time I/O is not needed.
Andrea Arcangeli wrote:
>
> On Wed, 13 Sep 2000, Martin Dalecki wrote:
>
> >"Jeff V. Merkey" wrote:
> >
> >> lessons learned in live customer accounts. In NetWare, requests are
> >> merged at A) the boundry between the File Cache and the I/O subsystem,
> >> and B) in the drivers themselves and
On Wed, Sep 13, 2000 at 04:59:22PM +0200, Andrea Arcangeli wrote:
> On Wed, 13 Sep 2000, Andi Kleen wrote:
>
> >function that is called from the drivers as needed. For smart devices
> >with very intelligent firmware you simply do not call it (assuming you
> >have decently sized kiovec requests,
On Wed, 13 Sep 2000, Andi Kleen wrote:
>function that is called from the drivers as needed. For smart devices
>with very intelligent firmware you simply do not call it (assuming you
>have decently sized kiovec requests, with the current bh approach some
>premerging is probably always needed)
On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote:
> About B) I can' believe you seriously want to duplicate the merging code
> in each lowlevel driver given most of them could share the same code (as
> they're doing in linux).
I guess it would just be a library call. e.g. the
If I understand your elevator algorithm, you switch between two queues, filling one
queue while
removing from another queue.
If you modify this to only be invoked when starvation of is detected, that is, to only
prevent
filling the removing queue when the oldest unsatisfied request exceeds
On Wed, 13 Sep 2000, Martin Dalecki wrote:
>"Jeff V. Merkey" wrote:
>
>> lessons learned in live customer accounts. In NetWare, requests are
>> merged at A) the boundry between the File Cache and the I/O subsystem,
>> and B) in the drivers themselves and NOT THE ELEVATOR.
>
>Yes that's the
Martin Dalecki wrote:
> "Jeff V. Merkey" wrote:
> >
> > Martin,
> >
> > I'm glad you are not still mad at me. :-) I hope this info was
> > helpful.
>
> Yes it was in fact this one of the more interresting posts in this
> thread. Thanks for the excellent reading. (However much of it
> sounded
On Wed, 13 Sep 2000, Martin Dalecki wrote:
"Jeff V. Merkey" wrote:
lessons learned in live customer accounts. In NetWare, requests are
merged at A) the boundry between the File Cache and the I/O subsystem,
and B) in the drivers themselves and NOT THE ELEVATOR.
Yes that's the proper place
If I understand your elevator algorithm, you switch between two queues, filling one
queue while
removing from another queue.
If you modify this to only be invoked when starvation of is detected, that is, to only
prevent
filling the removing queue when the oldest unsatisfied request exceeds
On Wed, Sep 13, 2000 at 04:29:18PM +0200, Andrea Arcangeli wrote:
About B) I can' believe you seriously want to duplicate the merging code
in each lowlevel driver given most of them could share the same code (as
they're doing in linux).
I guess it would just be a library call. e.g. the BSDs
On Wed, 13 Sep 2000, Andi Kleen wrote:
function that is called from the drivers as needed. For smart devices
with very intelligent firmware you simply do not call it (assuming you
have decently sized kiovec requests, with the current bh approach some
premerging is probably always needed)
I
On Wed, Sep 13, 2000 at 04:59:22PM +0200, Andrea Arcangeli wrote:
On Wed, 13 Sep 2000, Andi Kleen wrote:
function that is called from the drivers as needed. For smart devices
with very intelligent firmware you simply do not call it (assuming you
have decently sized kiovec requests, with the
Andrea Arcangeli wrote:
On Wed, 13 Sep 2000, Martin Dalecki wrote:
"Jeff V. Merkey" wrote:
lessons learned in live customer accounts. In NetWare, requests are
merged at A) the boundry between the File Cache and the I/O subsystem,
and B) in the drivers themselves and NOT THE
"Jeff V. Merkey" [EMAIL PROTECTED] said:
[...]
I have concluded that Linux will only progress as fast as Linus does. Linux
has forked twice now, and the new variants are not named "Linux" anymore, so
these types of changes may occur more quickly since there will be independent
paths.
"Jeff V. Merkey" wrote:
>
> Martin,
>
> I'm glad you are not still mad at me. :-) I hope this info was
> helpful.
Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the
Martin,
I'm glad you are not still mad at me. :-) I hope this info was
helpful.
:-)
Jeff
Martin Dalecki wrote:
>
> "Jeff V. Merkey" wrote:
>
> > lessons learned in live customer accounts. In NetWare, requests are
> > merged at A) the boundry between the File Cache and the I/O
"Jeff V. Merkey" wrote:
> lessons learned in live customer accounts. In NetWare, requests are
> merged at A) the boundry between the File Cache and the I/O subsystem,
> and B) in the drivers themselves and NOT THE ELEVATOR.
Yes that's the proper place to do this. The generic elevator on a
Hi Jeff,
since I vaguely remember an email from you describing how
you spent tweaking and changing
the disk IO elevator in Netware, and since we might want
to improve the Linux elevator sort a bit, could you give
us some hints on what to do and where not to waste our
time? ;)
thanks,
Rik
--
Hi Jeff,
since I vaguely remember an email from you describing how
you spent large amount of time tweaking and changing
the disk IO elevator in Netware, and since we might want
to improve the Linux elevator sort a bit, could you give
us some hints on what to do and where not to waste our
time?
"Jeff V. Merkey" wrote:
lessons learned in live customer accounts. In NetWare, requests are
merged at A) the boundry between the File Cache and the I/O subsystem,
and B) in the drivers themselves and NOT THE ELEVATOR.
Yes that's the proper place to do this. The generic elevator on a
Martin,
I'm glad you are not still mad at me. :-) I hope this info was
helpful.
:-)
Jeff
Martin Dalecki wrote:
"Jeff V. Merkey" wrote:
lessons learned in live customer accounts. In NetWare, requests are
merged at A) the boundry between the File Cache and the I/O subsystem,
and
"Jeff V. Merkey" wrote:
Martin,
I'm glad you are not still mad at me. :-) I hope this info was
helpful.
Yes it was in fact this one of the more interresting posts in this
thread. Thanks for the excellent reading. (However much of it
sounded very familiar... maybe they learned the same
36 matches
Mail list logo
