public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Dalecki <dalecki@evision-ventures.com>
To: Jens Axboe <axboe@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] IDE TCQ #4
Date: Mon, 15 Apr 2002 14:24:48 +0200	[thread overview]
Message-ID: <3CBAC690.8090908@evision-ventures.com> (raw)
In-Reply-To: <20020415125606.GR12608@suse.de>

Jens Axboe wrote:
> Hi,
> 
> Updated the patch to 2.5.8 (painful). Changes:

S*it - I did just offer you assistance... well you where faster.
Anyway thank you for going into this trouble.

Please allow me some notes anyway:

> 
> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
> --- /opt/kernel/linux-2.5.8/drivers/block/ll_rw_blk.c	2002-04-15 07:59:53.000000000 +0200
> +++ linux/drivers/block/ll_rw_blk.c	2002-04-15 08:42:23.000000000 +0200

I recognize the following makes sense but since
it's affecting every single type of device out there
it should go separetely to Linus I think...


> +  drive as a /\/\/\/\ queue size balance, where we could instead try and
> +  maintain a minimum queue size and get a /---------\ graph instead.

Nice drawings :-). But the help text shouldn't be
that encouraging right now IMHO... (At least
we should mark the options as experimental. (OK I will do that...)

> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8/drivers/ide/ide.c linux/drivers/ide/ide.c
> --- /opt/kernel/linux-2.5.8/drivers/ide/ide.c	2002-04-15 10:05:03.000000000 +0200
> +++ linux/drivers/ide/ide.c	2002-04-15 14:31:08.000000000 +0200
> @@ -381,8 +381,23 @@
>  		add_blkdev_randomness(major(rq->rq_dev));
>  
>  		spin_lock_irqsave(&ide_lock, flags);
> +
> +		if ((jiffies - ar->ar_time > ATA_AR_MAX_TURNAROUND) && drive->queue_depth > 1) {
> +			printk("%s: exceeded max command turn-around time (%d seconds)\n", drive->name, ATA_AR_MAX_TURNAROUND / HZ);
> +			drive->queue_depth >>= 1;
> +		}
> +
> +		if (jiffies - ar->ar_time > drive->tcq->oldest_command)
> +			drive->tcq->oldest_command = jiffies - ar->ar_time;
> +

time_before() and timer_after() should be used here.


>  	while ((read_timer() - hwif->last_time) < DISK_RECOVERY_TIME);

Same here.


I don't like that the following get's even more complicated.
But of course I will just have too look closer and understand it actually.

> +		if (0 < (signed long)(jiffies + WAIT_MIN_SLEEP - sleep))
> +			sleep = jiffies + WAIT_MIN_SLEEP;

The susual... timer_after() time_before()...

> -#ifdef CONFIG_BLK_DEV_IDEPCI
>  		if (hwif->pci_dev && !hwif->pci_dev->vendor)
> -#endif

Here I'm still not convinced whatever this should be implemented for
all architectures...


> -		memset(ar, 0, sizeof(*ar));
> +		memset(ar, 0, sizeof(ar));

Please look closer - I'm quite convinced that sizeof(ar) == sizeof(void *)
which gives not the desired effect. I have fixed this during the last
merge...

>  static int ide_check_media_change (kdev_t i_rdev)
> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8/drivers/ide/ide-disk.c linux/drivers/ide/ide-disk.c
> --- /opt/kernel/linux-2.5.8/drivers/ide/ide-disk.c	2002-04-15 07:59:53.000000000 +0200
> +++ linux/drivers/ide/ide-disk.c	2002-04-15 10:20:33.000000000 +0200
> @@ -107,10 +107,7 @@
>  	 * 48-bit commands are pretty sanely laid out
>  	 */
>  	if (lba48bit) {
> -		if (cmd == READ)
> -			command = WIN_READ_EXT;
> -		else
> -			command = WIN_WRITE_EXT;
> +		command = cmd == READ ? WIN_READ_EXT : WIN_WRITE_EXT;

Checking with GCC will reveal that the former version doesn't
generate worser code...

>  	return command;
> @@ -895,24 +894,24 @@
>  
>  		__set_bit(i, &tag_mask);
>  		len += sprintf(out+len, "%d, ", i);
> -		if (ar->ar_time > max_jif)
> -			max_jif = ar->ar_time;
> +		if (cur_jif - ar->ar_time > max_jif)
> +			max_jif = cur_jif - ar->ar_time;

I disgust timer calculartions...- will have to look at a way
how to nap in a similar way eth drivers do.

> diff -urN -X /home/axboe/cdrom/exclude /opt/kernel/linux-2.5.8/drivers/ide/ide-dma.c linux/drivers/ide/ide-dma.c
> --- /opt/kernel/linux-2.5.8/drivers/ide/ide-dma.c	2002-04-15 07:59:53.000000000 +0200
> +++ linux/drivers/ide/ide-dma.c	2002-04-15 09:17:55.000000000 +0200
>
> +#endif /* CONFIG_BLK_DEV_IDE_TCQ */
>  
>  		case ide_dma_read:
>  			reading = 1 << 3;
>  		case ide_dma_write:
> -			ar = HWGROUP(drive)->rq->special;
> +			ar = IDE_CUR_AR(drive);

Ahhh!!! I'm gald to see this.


>  
>  static inline void drive_ctl_nien(ide_drive_t *drive, int clear)
>  {
>  #ifdef IDE_TCQ_NIEN
> -	int mask = clear ? 0 : 2;
> +	int mask = clear ? 0 : 1 << 1;
????


> -			BUG_ON(drive->tcq->active_tag == -1);
> +			BUG_ON(drive->tcq->active_tag == IDE_INACTIVE_TAG);

IDE_IDLE_TAG would sound better I think... but no argument here.


> -#define IDE_CUR_AR(drive)	\
> -	((drive)->using_tcq ? IDE_CUR_TAG((drive)) : HWGROUP((drive))->rq->special)
> +#define IDE_CUR_AR(drive)	(HWGROUP((drive))->rq->special)

Ahh that's nice :-). Let's look further down how this coexists with ide-cd.c...


> -extern inline int ide_get_tag(ide_drive_t *drive)
> +static inline int ide_get_tag(ide_drive_t *drive)

OK. I have missed this one apparently.

ar_timer will make it at least esier to finish the ide-cd.c transition
to this data transport base.

Should I just quickly remerge this, so we can work further from
the same code base to ease the merging pain?


  reply	other threads:[~2002-04-15 13:26 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-15 12:56 [PATCH] IDE TCQ #4 Jens Axboe
2002-04-15 12:24 ` Martin Dalecki [this message]
2002-04-15 13:33   ` Jens Axboe
2002-04-15 12:39     ` Martin Dalecki
2002-04-15 16:13 ` Aaron Tiensivu
2002-04-15 16:18   ` Jens Axboe
2002-04-15 16:44     ` Jens Axboe
2002-04-16 10:25   ` Jens Axboe
     [not found]     ` <20020416200051.7ae38411.sebastian.droege@gmx.de>
     [not found]       ` <20020416180914.GR1097@suse.de>
2002-04-16 18:43         ` Sebastian Droege
2002-04-17  7:48           ` Martin Dalecki
2002-04-17 11:28             ` Sebastian Droege
2002-04-17 10:32               ` Martin Dalecki
2002-04-17 11:40                 ` Sebastian Droege
2002-04-17 10:42               ` Martin Dalecki
2002-04-18 12:17                 ` Sebastian Droege
2002-04-18 11:20                   ` Martin Dalecki
2002-04-18 12:26                     ` Sebastian Droege
2002-04-18 12:57                       ` Jens Axboe
2002-04-18 12:57                     ` Jens Axboe
2002-04-18 11:59                       ` Martin Dalecki
2002-04-18 13:07                         ` Jens Axboe
2002-04-18 12:08                           ` Martin Dalecki
2002-04-18 13:12                             ` Jens Axboe
2002-04-18 12:16                               ` Martin Dalecki
2002-04-18 13:26                                 ` Jens Axboe
2002-04-18 12:40                                   ` Martin Dalecki
2002-04-18 12:45                                     ` Martin Dalecki
2002-04-18 14:17                               ` Alan Cox
2002-04-18 13:01                   ` Jens Axboe
2002-04-17  7:32     ` Helge Hafting
2002-04-17 13:01       ` Dave Jones
2002-04-17 13:05         ` Jens Axboe
2002-04-30 19:58     ` Martin Schewe
  -- strict thread matches above, loose matches on Subject: below --
2002-04-15 18:41 Petr Vandrovec
2002-04-15 18:26 ` Jens Axboe
2002-04-16  5:11 ` Martin Dalecki
2002-04-15 19:11 Petr Vandrovec
2002-04-15 19:28 Petr Vandrovec
2002-04-16 10:25 ` Jens Axboe
2002-04-16 11:01   ` Martin Dalecki
2002-04-16 12:28     ` Jens Axboe
2002-04-16 11:44       ` Martin Dalecki
2002-04-15 19:29 Petr Vandrovec
2002-04-15 19:00 ` Jens Axboe
2002-04-18 22:05 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=3CBAC690.8090908@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox