Jens Axboe wrote:
> On Mon, Dec 04 2000, Russell Cattelan wrote:
> > I'm going to take a closer look at the scsi_back_merge_fn.
> > This may have more to due with our/Chait's kiobuf modifications than
> > anything else.
> >
> >
> >
> > XFS (dev: 8/20) mounting with KIOBUFIO
> > Start mounting
On Mon, Dec 04 2000, Russell Cattelan wrote:
> I'm going to take a closer look at the scsi_back_merge_fn.
> This may have more to due with our/Chait's kiobuf modifications than
> anything else.
>
>
>
> XFS (dev: 8/20) mounting with KIOBUFIO
> Start mounting filesystem: sd(8,20)
> Ending clean
On Mon, Dec 04 2000, Russell Cattelan wrote:
I'm going to take a closer look at the scsi_back_merge_fn.
This may have more to due with our/Chait's kiobuf modifications than
anything else.
XFS (dev: 8/20) mounting with KIOBUFIO
Start mounting filesystem: sd(8,20)
Ending clean XFS
Jens Axboe wrote:
On Mon, Dec 04 2000, Russell Cattelan wrote:
I'm going to take a closer look at the scsi_back_merge_fn.
This may have more to due with our/Chait's kiobuf modifications than
anything else.
XFS (dev: 8/20) mounting with KIOBUFIO
Start mounting filesystem:
Jens Axboe wrote:
> On Fri, Dec 01 2000, Russell Cattelan wrote:
> > > If performance is down, then that problem is most likely elsewhere.
> > > I/O limited benchmarking typically thrives on lots of request
> > > latency -- with that comes better throughput for individual threads.
> > >
> > > >
Jens Axboe wrote:
> On Fri, Dec 01 2000, Russell Cattelan wrote:
> > > If performance is down, then that problem is most likely elsewhere.
> > > I/O limited benchmarking typically thrives on lots of request
> > > latency -- with that comes better throughput for individual threads.
> > >
> > > >
Jens Axboe wrote:
On Fri, Dec 01 2000, Russell Cattelan wrote:
If performance is down, then that problem is most likely elsewhere.
I/O limited benchmarking typically thrives on lots of request
latency -- with that comes better throughput for individual threads.
Anyway, I'll try
On Fri, Dec 01 2000, Russell Cattelan wrote:
> > If performance is down, then that problem is most likely elsewhere.
> > I/O limited benchmarking typically thrives on lots of request
> > latency -- with that comes better throughput for individual threads.
> >
> > > Anyway, I'll try your patch.
>
On Fri, Dec 01 2000, Russell Cattelan wrote:
If performance is down, then that problem is most likely elsewhere.
I/O limited benchmarking typically thrives on lots of request
latency -- with that comes better throughput for individual threads.
Anyway, I'll try your patch.
Well this
Jens Axboe wrote:
> On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
> > > Believe it or not, but this is intentional. In that regard, the
> > > function name is a misnomer -- call it i/o scheduler instead :-)
> >
> > I never believe it intentional. If it is true, the current kernel
> > will be
Jens Axboe wrote:
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
Believe it or not, but this is intentional. In that regard, the
function name is a misnomer -- call it i/o scheduler instead :-)
I never believe it intentional. If it is true, the current kernel
will be suffered from
On Wed, 22 Nov 2000 [EMAIL PROTECTED] wrote:
> The current Linux has a lot of difficult to set parameters in
> /proc/sys.
> Once a system goes beyond some settable limits, the system behavior
> changes so sharp. Bdf_prm.nrfract in fs/buffer.c is one of the
> difficult parameters. I hope a
On Wed, 22 Nov 2000 [EMAIL PROTECTED] wrote:
The current Linux has a lot of difficult to set parameters in
/proc/sys.
Once a system goes beyond some settable limits, the system behavior
changes so sharp. Bdf_prm.nrfract in fs/buffer.c is one of the
difficult parameters. I hope a tool to
On Tue, Nov 21, 2000 at 05:28:40PM +0900, [EMAIL PROTECTED] wrote:
> @@ -47,6 +47,11 @@
> break;
> tmp->elevator_sequence--;
> }
> + if (entry == head) {
> + tmp = blkdev_entry_to_request(entry);
> + if (IN_ORDER(req, tmp))
> +
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
> > The problem is caused by the too high sequence numbers in stock
> > kernel, as I said. Plus, the sequence decrementing doesn't take
> > request/buffer size into account. So the starvation _is_ limited,
> > the limit is just too high.
>
> Yes,
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
> > Believe it or not, but this is intentional. In that regard, the
> > function name is a misnomer -- call it i/o scheduler instead :-)
>
> I never believe it intentional. If it is true, the current kernel
> will be suffered from a kind of DOS
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
> The current elevator_linus() doesn't obey the true elevator
> scheduling, and causes I/O livelock during frequent random write
> traffics. In such environment I/O (read/write) transactions may be
> delayed almost infinitely (more than 1 hour).
>
>
The current elevator_linus() doesn't obey the true elevator
scheduling, and causes I/O livelock during frequent random write
traffics. In such environment I/O (read/write) transactions may be
delayed almost infinitely (more than 1 hour).
Problem:
Current elevator_linus() traverses the I/O
The current elevator_linus() doesn't obey the true elevator
scheduling, and causes I/O livelock during frequent random write
traffics. In such environment I/O (read/write) transactions may be
delayed almost infinitely (more than 1 hour).
Problem:
Current elevator_linus() traverses the I/O
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
The current elevator_linus() doesn't obey the true elevator
scheduling, and causes I/O livelock during frequent random write
traffics. In such environment I/O (read/write) transactions may be
delayed almost infinitely (more than 1 hour).
On Tue, Nov 21, 2000 at 05:28:40PM +0900, [EMAIL PROTECTED] wrote:
@@ -47,6 +47,11 @@
break;
tmp-elevator_sequence--;
}
+ if (entry == head) {
+ tmp = blkdev_entry_to_request(entry);
+ if (IN_ORDER(req, tmp))
+
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
The problem is caused by the too high sequence numbers in stock
kernel, as I said. Plus, the sequence decrementing doesn't take
request/buffer size into account. So the starvation _is_ limited,
the limit is just too high.
Yes, current
On Tue, Nov 21 2000, [EMAIL PROTECTED] wrote:
Believe it or not, but this is intentional. In that regard, the
function name is a misnomer -- call it i/o scheduler instead :-)
I never believe it intentional. If it is true, the current kernel
will be suffered from a kind of DOS attack.
23 matches
Mail list logo
