> It is currently as fairly clean as the following, but this will probably
> become worse later, IMO, if it not _really_ cleaned as it deserves:
>
> ./drivers/block/ide.c: if (bdev->current_request != &bdev->plug)
Every block driver has to have such a line. The current plug
mehanism is only good if it is checked for and honoured by the
low level driver, as the only thing which plug_device() does
is:
dev->current_request = &dev->plug;
Some drivers might check it as follows (like the SCSI driver):
if (CURRENT != NULL && CURRENT->rq_status == RQ_INACTIVE) {
return;
}
which is the same thing, as dev->plug is initialized as:
dev->plug.rq_status = RQ_INACTIVE;
dev->plug.cmd = -1;
> ./drivers/block/ide.c: if (bdev->current_request != &bdev->plug) /* FIXME: this will do for now */
> ./drivers/block/ide.c: if (bdev->current_request == &bdev->plug) /* FIXME: paranoia */
> ./drivers/block/ide.c: printk("%s: Huh? nuking plugged queue\n", drive->name);
All the above are not needed in my opinion.
> ./drivers/block/raid5.c:static void unplug_devices(struct stripe_head *sh)
> ./drivers/block/raid5.c: unplug_device(blk_dev + MAJOR(raid_conf->disks[i].dev));
> ./drivers/block/raid5.c: int i, handled = 0, unplug = 0;
> ./drivers/block/raid5.c: unplug = 1;
> ./drivers/block/raid5.c: unplug = 1;
> ./drivers/block/raid5.c: if (unplug) {
> ./drivers/block/raid5.c: PRINTK(("unplugging devices, sector == %lu, count == %d\n", sh->sector, raid_conf->sector_count));
> ./drivers/block/raid5.c: unplug_devices(sh);
> ./drivers/block/raid5.c: unplug = 0;
>
> Note that in the raid code, this fairly clean thing is just #ifed ZERO.
I wrote this code as well, but when we originally designed the RAID-5
driver, in 2.0.x, before the get_queue() addition, and isn't related to
it at all. It is #if'd 0 just because we couldn't justify the additional
complexity with actual performance figures.
This code just tried to:
1. unplug only specific majors which include the disks in the
RAID set rather then using run_task_queue() which will unplug
all devices. Nothing unclean about that; the lower the granularity
the better, in my opinion.
2. Try to overlap I/O while perfroming some other processing.
I agree with Eric's suggestion of having a per kdev_t "descriptor". This
can include various things, just as a private queue, a private plug if
we decide continuing using that, and even private dirty list for buffer.c,
private hash table for buffer lookup, statistics about the current
and maximum device speed (which could be used to tune the kflushd()
daemon), etc.
Gadi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/