I just remembered that I put binaries and diffs up on my web page a long
time ago.
http://www.andante.org/sim.html
These are all based on the 2.3.8 kernel, and there are two versions -
one with the new queueing code (or an early and incomplete version of it),
and one without. There is one caveat - when I built the version without the
new queueing code, I had been testing to see what happens when you have a
sector size of 2248 (mainly to make sure that the thing didn't crash, as I
saw a report that it did crash with 2.2.x). I forgot to set this back when
I uploaded binaries. It is left as an exercise to the reader to hack the
thing in the debugger and force the sector size back something like 512 :-).
I will be the first to admit that the thing is a real hack, and it was a
real pain in the neck to maintain. Nonetheless, for the queueing rewrite it
was an imense help - the compile/link/run/debug cycles get to be quite
short, and as a general rule I prefer to step through new code with a
debugger once or twice to make sure that it is doing what I intended it to
do. If anyone is interested in helping to bring the thing uptodate, I have
some ideas for much cleaner ways of doing it, and ways of generalizing it to
make it possible to debug things like filesystems and whatnot.
I looked at the SCSI queue handler function - it looks like I am
correctly testing for the plugged flag at the start of it and returning if
this condition is true. It is possible that I introduced a bug in the
ll_rw_blk layer at the time of the queueing rewrite which could have broken
plugging to some degree. The major change that I made at this level was to
eliminate the phony request that we used to stick at the head, and replace
it with a simple boolean flag "q->plugged".
As it turns out, we had a bunch of snow last night, and I am kind of
stuck indoors. I will probably play with this myself some. I do get the
day off of work, though :-).
-Eric
----- Original Message -----
From: "Jens Axboe" <[EMAIL PROTECTED]>
To: "Eric Youngdale" <[EMAIL PROTECTED]>
Cc: "Alan Cox" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, January 25, 2000 10:18 AM
Subject: Re: request merge changes?
> On Tue, Jan 25 2000, Eric Youngdale wrote:
> [broken request merging]
> > If I had to take a guess, I would venture that the problem has to do
> > with the way that plugging was implemented. I believe that what is
going on
> > is that read ahead isn't kicking in until after the first read request.
> > Thus you get a really small request for the first one, and once the
block
> > driver notices that you are requesting consecutive blocks, read-ahead
starts
> > to kick in and the request size starts to increase.
>
> But this if for writes, not reads. I haven't investigated the read aheads
> yet, but the device plugging may be guilty for the writing as well.
>
> > The other thing that I have been noticing - some people have
complained
> > that the request size never exceeds 64K. My *guess* here is that what
we
> > are doing is inserting the plug, requesting the sectors for an entire
page
> > of memory, and then unplugging. This cannot be the entire explaination,
as
> > once the device is busy and no longer accepting requests, plugging
becomes
> > irrelevant.
>
> The ll_rw_block layer will not merge requests beyond max_sectors /
> max_segments which, again, is a per-major kind of thing. Has anyone
> experimented with setting this higher? The DAC960 is currently
> the only driver manipulating it. The default value is indeed 128
> sectors, or 64KB.
>
> > For SCSI disks, the read ahead is set to 120 sectors - just a tad
under
> > 64K. For SCSI CDROM, it is set to 32 sectors - the thing I am not sure
> > about is whether this always refers to "sectors" of 512 bytes, or it
> > reflects the hardware sectorsize. Look for "read_ahead" in both sd.c
and
> > sr.c to see where this is set.
>
> Even though the readahead should be set as low as 120 sectors (512
> byte units here), there would be nothing wrong in allowing a much
> large clustered request. But hey, the drivers can pick and choose
> it's just that noone is doing it yet.
>
> > If I could get the simulator running again, you could just step
through
> > the kernel with gdb and see for yourself how all of this stuff
interacts.
> > Then again, I probably have an older executable based upon a 2.3.8
kernel
> > which you could probably run - let me take a look tonight.
>
> I'd like to see it.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
