From: Martin Dalecki <dalecki@evision-ventures.com>
To: Jens Axboe <axboe@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][CFT] IDE TCQ #2
Date: Tue, 09 Apr 2002 14:24:20 +0200 [thread overview]
Message-ID: <3CB2DD74.30700@evision-ventures.com> (raw)
In-Reply-To: <20020409124417.GK25984@suse.de>
Hello.
Since I have been experimenting with your initial release
yerstoday, please allow me some more detailed notes about the code:
> echo "using_tcq:0" > /proc/ide/hdX/setting
>
> will disable TCQ and revert to DMA,
>
> echo "using_tcq:32" > /proc/ide/hdX/setting
>
> will set queue depth to 32, any value in between the two are of course
> also allowed. The driver will print enable/disable info to the kernel
> log.
Well this belongs to an ioctl or sysctl... However most
of the /proc/ide stuff if not all will go to the sysctl quite soon.
> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8-pre2/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
> --- /opt/kernel/linux-2.5.8-pre2/drivers/block/ll_rw_blk.c Mon Mar 18 21:37:05 2002
> +++ linux/drivers/block/ll_rw_blk.c Tue Apr 9 10:35:20 2002
> @@ -857,10 +857,10 @@
> spin_lock_prefetch(q->queue_lock);
>
> generic_unplug_device(q);
> - add_wait_queue(&rl->wait, &wait);
> + add_wait_queue_exclusive(&rl->wait, &wait);
> do {
> set_current_state(TASK_UNINTERRUPTIBLE);
> - if (rl->count < batch_requests)
> + if (!rl->count)
> schedule();
> spin_lock_irq(q->queue_lock);
> rq = get_request(q, rw);
> @@ -1683,9 +1683,11 @@
> * Free request slots per queue.
> * (Half for reads, half for writes)
> */
> - queue_nr_requests = 64;
> - if (total_ram > MB(32))
> - queue_nr_requests = 256;
> + queue_nr_requests = (total_ram >> 8) & ~15; /* One per quarter-megabyte */
> + if (queue_nr_requests < 32)
> + queue_nr_requests = 32;
> + if (queue_nr_requests > 256)
> + queue_nr_requests = 256;
This adaptive behaviour seems to be better fitting possible
ram sized those days indeed.
> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8-pre2/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
> --- /opt/kernel/linux-2.5.8-pre2/drivers/ide/ide-disk.c Tue Apr 9 11:41:13 2002
> +++ linux/drivers/ide/ide-disk.c Tue Apr 9 10:29:46 2002
> @@ -26,9 +26,10 @@
> * Version 1.11 Highmem I/O support, Jens Axboe <axboe@suse.de>
> * Version 1.12 added 48-bit lba
> * Version 1.13 adding taskfile io access method
> + * Version 1.14 Added tcq support, Jens Axboe <axboe@suse.de>
> */
>
> -#define IDEDISK_VERSION "1.13"
> +#define IDEDISK_VERSION "1.14"
>
> #include <linux/config.h>
> #include <linux/module.h>
> @@ -109,53 +110,64 @@
> static u8 get_command(ide_drive_t *drive, int cmd)
> {
> int lba48bit = (drive->id->cfs_enable_2 & 0x0400) ? 1 : 0;
> + int command = WIN_NOP;
The "incremental" usage of the command variable I think is an overoptimization.
u8 is the proper type for it anyway. I have unwound the code below once
to make it more obvious and you would be surprised what GCC does with it :-).
> +
> + return command;
> }
See you are returning an int entity as u8!
> + ide_task_t *args = &ar->ar_task;
> + struct request *rq = ar->ar_rq;
Hints that ide_task_t and ata_request_t and struct request usage
belong together. This could alleviate the ugly usage of the
rq->special field if rq is struct request - which would be a GoodThin(TM).
> + args->ar = ar;
> + rq->special = ar;
Same hint as above.
>n ata_taskfile(drive,
> - &args.taskfile,
> - &args.hobfile,
> - args.handler,
> - args.prehandler,
> + &args->taskfile,
> + &args->hobfile,
> + args->handler,
> + args->prehandler,
> rq);
Due to the other cleanups which happened already it was now possible
for me to collapse the arguments of the ata_taskfile function to
use only one parameter - names ide_task_t. This will immediately allow
to consolidate all data specific to a command into one queued structure,
which will be named struct ata_request then. I will post the
corresponding patch just immediately, since the integration of the
tcq stuff will be quite involved with it.
> + ide_task_t *args = &ar->ar_task;
> + struct request *rq = ar->ar_rq;
See agin they belong together.
> + args->ar = ar;
> + rq->special = ar;
> + ide_task_t *args = &ar->ar_task;
> + struct request *rq = ar->ar_rq;
and again.
> + args->ar = ar;
> + rq->special = ar;
and again they belong together and strcut request should not be passed
as parameter in IDE code.
> - return lba48_do_request(drive, rq, block);
> + return lba48_do_request(drive, ar, block);
>
> /* 28-bit LBA */
> if (drive->select.b.lba)
> - return lba28_do_request(drive, rq, block);
> + return lba28_do_request(drive, ar, block);
>
> /* 28-bit CHS */
> - return chs_do_request(drive, rq, block);
> + return chs_do_request(drive, ar, block);
Didn't I tell we shouldn't be tossing request structs around? :-).
> +/*
> + * FIXME: taskfiles should be a map of pages, not a long virt address... /jens
> + */
I fully agree with you - possible it will be helpfull to just pee at
the SCSI code to see how it should be done...
> + if (rq->flags & REQ_DRIVE_TASKFILE)
> + ar->ar_sg_nents = ide_raw_build_sglist(hwif, rq);
> + else
> + ar->ar_sg_nents = ide_build_sglist(hwif, rq);
Most certainly the switch should be pushed down to one sinde
build_sglist function - we are passing the rq anyway to it.
> @@ -372,10 +378,9 @@
> void ide_destroy_dmatable (ide_drive_t *drive)
> {
> struct pci_dev *dev = drive->channel->pci_dev;
> - struct scatterlist *sg = drive->channel->sg_table;
> - int nents = drive->channel->sg_nents;
> + ata_request_t *ar = IDE_CUR_AR(drive);
This looks a bit ugly and should be analogous to ata_ar_get()
possible ata_ar_current() will fit.
> +int ide_start_dma(struct ata_channel *hwif, ide_drive_t *drive, ide_dma_action_t func)
> +{
> + unsigned int reading = 0, count;
> + unsigned long dma_base = hwif->dma_base;
> + ata_request_t *ar = IDE_CUR_AR(drive);
> +
> + if (rq_data_dir(ar->ar_rq) == READ)
> + reading = 1 << 3;
> +
> + if (hwif->rwproc)
> + hwif->rwproc(drive, func);
> +
> + if (!(count = ide_build_dmatable(drive, ar->ar_rq, func)))
> + return 1; /* try PIO instead of DMA */
> +
> + ar->ar_flags |= ATA_AR_SETUP;
> + outl(ar->ar_dmatable, dma_base + 4); /* PRD table */
> + outb(reading, dma_base); /* specify r/w */
> + outb(inb(dma_base + 2) | 6, dma_base+2);/* clear INTR & ERROR flags */
Hmmm there is one architecture which will have possbile problems with this
namely cris. But right now I'm quite convinced that they should fix something
there and the OUT_ IDE code specific compatibility macros should be removed
altogether.
> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8-pre2/drivers/ide/ide-features.c linux/drivers/ide/ide-features.c
> --- /opt/kernel/linux-2.5.8-pre2/drivers/ide/ide-features.c Tue Apr 9 11:41:13 2002
> +++ linux/drivers/ide/ide-features.c Thu Apr 4 08:14:18 2002
> @@ -75,10 +75,7 @@
> char *ide_dmafunc_verbose (ide_dma_action_t dmafunc)
> {
> switch (dmafunc) {
> - case ide_dma_read: return("ide_dma_read");
> - case ide_dma_write: return("ide_dma_write");
> case ide_dma_begin: return("ide_dma_begin");
> - case ide_dma_end: return("ide_dma_end:");
> case ide_dma_check: return("ide_dma_check");
> case ide_dma_on: return("ide_dma_on");
> case ide_dma_off: return("ide_dma_off");
This abortion will be killed by using __FUNCTION__ where apriopriate in
debugging code.
> + ata_request_t *ar = rq->special;
> + ide_task_t *args = &ar->ar_task;
Did I mention they belong to a single entity :-).
> - ide_task_t *args = HWGROUP(drive)->rq->special;
> + ata_request_t *ar = HWGROUP(drive)->rq->special;
> + ide_task_t *args = &ar->ar_task;
Same comment here.
> + ata_request_t *ar = rq->special;
> + ide_task_t *args = &ar->ar_task;
And here.
OK I will just "eat" your code this evening...
next prev parent reply other threads:[~2002-04-09 13:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-09 12:44 [PATCH][CFT] IDE TCQ #2 Jens Axboe
2002-04-09 12:24 ` Martin Dalecki [this message]
2002-04-09 13:41 ` Jens Axboe
2002-04-10 8:55 ` Martin Dalecki
2002-04-10 9:58 ` Jens Axboe
2002-04-10 9:04 ` Martin Dalecki
2002-04-10 10:09 ` Jens Axboe
2002-04-10 9:12 ` Martin Dalecki
-- strict thread matches above, loose matches on Subject: below --
2002-04-09 15:34 Andries.Brouwer
2002-04-09 15:22 ` Martin Dalecki
2002-04-09 16:38 Andries.Brouwer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CB2DD74.30700@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.