Messages in this thread | | | Date | Mon, 17 Nov 1997 19:16:38 -0500 | From | mlord <> | Subject | Re: possible bug in ll_rw_blk.c in 2.0.x and 2.1.x |
| |
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
| |