[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0903021048570.3111@localhost.localdomain>
Date: Mon, 2 Mar 2009 10:54:35 -0800 (PST)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Vadim Lobanov <vlobanov@...akeasy.net>
cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
lkml <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] irq: remove IRQF_DISABLED
On Mon, 2 Mar 2009, Vadim Lobanov wrote:
> On Monday 02 March 2009 09:11:54 Linus Torvalds wrote:
> > The thing is, with PIO, a 512-byte disk read ends up doing 256 16-bit word
> > reads from the controller, each potentially up to 600ns long (PIO0
> > timings). That's 150ms - for a single sector!
>
> Out of curiosity, the peanut gallery wishes to ask:
> Is the above supposed to be 600us (*1000), or 150us (/1000)? Probably the
> latter.
Sorry, I was off by a lot. Yes. /1000. The end result ends up being lots
better (and I should have realized I did my conversion wrong, because the
times ended up being _so_ big), but not better enough - we've had dropped
timer interrupts etc on those kinds of machines unless you use "hdparm -u1".
Although it porbably does mean that the problem tends to be more in the
really bad mode0 case (600ns -> 150us/sector -> milliseconds for
multi-sector transfers).
I forget what our multi-sector limit is, I think it tends to be 16. So
you'll never get _really_ long irq-off times, but "several ms" is still
pretty damn bad.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists