[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [PATCH] 2.5.24 IDE 95 (fwd)
From:       Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz () elka ! pw ! edu ! pl>
Date:       2002-06-30 16:52:58
[Download RAW message or body]

I hope you dont mind Petr.

---------- Forwarded message ----------
Date: Sun, 30 Jun 2002 18:20:03 +0200 (MET DST)
From: Bartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
To: Petr Vandrovec <vandrove@vc.cvut.cz>
Subject: Re: [PATCH] 2.5.24 IDE 95


Hi!

On Sun, 30 Jun 2002, Petr Vandrovec wrote:

> On Sun, Jun 30, 2002 at 12:53:57AM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi Petr!
> >
> > On Sun, 30 Jun 2002, Petr Vandrovec wrote:
> >
> > > Hi,
> > >   I know that IDE95 is broken when it comes to IDE, but... not only
>
> Oops. It should read ... when it comes to CD, ...
> Thanks for your updates, applying them just now.
> 							Petr
>
> P.S.: Locking looks suspicious too. On other side, if hardware is broken
> and requires large data transfers during interrupt, why we should
> bother? ne2000 driver always required disabling interrupts for up to 1.6ms...

1.6ms really bad, masked PIO is about 2ms, this can affect audio etc.,
Legacy/special/broken hardware does only PIO, but most of it do not
require transfers with IRQs disabled (thats why ch->unmask flag).

Even with new locking (ch->lock for everything) we don't have to disable
IRQs completly, we can mask our IRQ and enable rest, but it is not
possible to i.e. share IRQ with audio (because we disable our IRQ).
It was (at least in theory) possible with old locking.

Old locking is that ch->lock spinlock protects access to IDE_BUSY bit in
ch->active, ch->handler and ch->timer. IDE_BUSY protects hardware access,
if it is set we do not enter start_request() in do_request(). When we start
request block layer sets RQ_STARTED flag on request so it is protected
from block layer side. Thats almost all about locking.

Hope this clarifies some things, also old akpm's note about IDE
unmaskirqs attached....

Greets.
--
Bartlomiej

["ide-intr.txt" (TEXT/PLAIN)]

Date: Sat, 22 Apr 2000 01:51:54 +1000
From: Andrew Morton <andrewm@uow.edu.au>
Subject: Re: IDE drives and unmaskirq

[ I cut lkml - I've been posting too much today :) ]

Martijn van Oosterhout wrote:
> 
> Odd, both my hard disks are UDMA. You're saying unmaskirq has
> no effect on UDMA systems?

I have a patch which measures interrupt latencies.  It tells you how
long the kernel spends with interrupts disabled: where they were turned
off, where they were turned on, min, max, avg number of microseconds.

With UDMA66 drives:

hdparm -u0 -d0  (interrupts masked, PIO)

                                   Count   Min      Max      Avg
ide-disk.c:451 -> ll_rw_blk.c:277  12     825.17  2350.14  1268.35
     ide-disk.c:451 -> ide.c:1620  591    818.82  2172.18  1138.26
         ide.c:1531 -> ide.c:1620  7407    12.13  2147.32  1519.29
         ide.c:1531 -> ide.c:1296  721      9.51  1930.11   236.73
    ll_rw_blk.c:271 -> ide.c:1296  2912    13.82    27.89    16.56
         ...

hdparm -t says 4.1 MB/sec

(The first traversal seems a very odd place to reenable...)

-------

hdparm -u0 -d1 (interrupts masked, DMA)

     ide.c:1531 -> ide.c:1620  5230     11.13    90.76    26.55
     ide.c:1531 -> ide.c:1296  484      11.53    73.15    17.15
ll_rw_blk.c:271 -> ide.c:1296  5232     13.79    28.07    16.51
ide.c:1298 -> ll_rw_blk.c:277  5232      7.33    14.40     8.23
      ...

hdparm -t says 21 MB/sec

------

hdparm -u1 -d0 (interrupts unmasked, PIO)

          ide.c:522 -> ide.c:531  8631     .81    32.30     1.93
   ll_rw_blk.c:271 -> ide.c:1296  3921   13.82    28.94    16.52
          ide.c:497 -> ide.c:506  14388   1.07    24.79     6.07
   ide.c:1298 -> ll_rw_blk.c:277  3921    7.33    14.76     8.15
         ...

hdparm -t says 4.2 MB/sec

--------

hdparm -u1 -d1 (interrupts unmasked, DMA)

ll_rw_blk.c:271 -> ide.c:1296  3950     13.78    26.74    16.43
     ide.c:1713 -> ide.c:1296  1        23.61    23.61    23.61
       ide.c:497 -> ide.c:506  14623      .99    23.22     5.06
ide.c:1298 -> ll_rw_blk.c:277  3950      7.35    15.72     8.11
         ...

hdparm -t says 22 MB/sec


So you can see that even with DMA, 'hdparm -u1' cuts the max
interrupt-disable time from 90 to 27 microseconds.  I somehow doubt if
that will affect interactive perceptions, but the two milliseconds for
PIO/masked will affect audio, for example.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[prev in list] [next in list] [prev in thread] [next in thread]