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

On Mon, Apr 15 2002, Martin Dalecki wrote:
> 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.

:-)

> >
> >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...

They have.

> >+  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...)

It's no more experiemental than the rest of it, in fact all my testing
has been with _FULL option enabled right now. So I'd basically say it's
the recommended setting :-)

> >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.

Not necessarily, the above is wrap safe.

> > 	while ((read_timer() - hwif->last_time) < DISK_RECOVERY_TIME);
> 
> Same here.

Ditto, at least for this one I agree that readibility would be better
with the macros.

> >-#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...

Agree, we can leave this the way it was for now and just do the nasty
ifdefs.

> >-		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...

Irk, where did that come from?! Had you done the incremental patches
this would not have slipped through! My mistake.

> > 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...

I had already rewritten it by the time your changed version was out, so
it was simply unchanged.

> > 	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.

? This is just statistics. There absolutely nothing wrong with the
above.

> >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;
> ????

Just more readable that we are setting bit 2.

> >-#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?

Sure, go ahead. And do the changes they way we discussed earlier today,
ok? :)

-- 
Jens Axboe


  reply	other threads:[~2002-04-15 13:33 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
2002-04-15 13:33   ` Jens Axboe [this message]
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=20020415133326.GT12608@suse.de \
    --to=axboe@suse.de \
    --cc=dalecki@evision-ventures.com \
    --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.