Re: possible bug in ll_rw_blk.c in 2.0.x and 2.1.x

mlord (mlord@pobox.com)
Mon, 17 Nov 1997 19:16:38 -0500

Kelly French wrote:
>
> Ok, here's my fix for this. What it does is remove all of the 4-entry
> arrays from kstat and replaces them with a linked list holding all the old
> data types along with which device it belongs to. I also preload 4 empty
> devices so that at boot up it still works for programs expecting 4
> entries. Once you hit 5 entries your programs may GPF :-)
...
> + prev_drive = NULL;
> + tmp_drive = kstat.disk_stat;
> + while (tmp_drive && tmp_drive->dk_dev && (tmp_drive->dk_dev != temp_dev)) {
> + prev_drive = tmp_drive;
> + tmp_drive = tmp_drive->next;
> }
> + /* a record is empty on dk_dev == 0, use it if you can */
> + if (!tmp_drive)
> + tmp_drive = add_stat_drive(prev_drive, temp_dev);
> + else if (!tmp_drive->dk_dev)
> + tmp_drive->dk_dev = temp_dev;
> + if (tmp_drive)
> + drive_stat_acct(req->cmd, req->nr_sectors, tmp_drive);

Okay folks, any chance of simplifying life here in add_request() ??

This is the mainline path for I/O, and we really ought to keep
unnecessary overhead to a minimum.

I'm not sure that a linear search of a linked list for statistics
is the best thing to have on a mainline performance-impacting
path..

Got any alternatives, like a simple table by device number or something?

Let the /proc/stat stuff do the table search to find the top four
drives.

-ml