lkml.org 
[lkml]   [1997]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.065 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site