[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <45768F84.7090707@gmail.com>
Date: Wed, 06 Dec 2006 18:38:12 +0900
From: Tejun Heo <htejun@...il.com>
To: Arjan van de Ven <arjan@...radead.org>
CC: Jeff Garzik <jeff@...zik.org>, Mikael Pettersson <mikpe@...uu.se>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19 2/3] sata_promise: new EH conversion
Arjan van de Ven wrote:
>> But, having those flushes won't hurt either. What was the conclusion of
>> mmio <-> spinlock sync discussion? I always feel kind of uncomfortable
>> about readl() flushes. I think they're too subtle.
>
> those are orthogonal!
> The posting flushes have nothing to do with spinlock-vs-mmio; that
> discussion was about the CPU, while posting flushes are about the
> chipset / bridges / etc....
The problem is that it's not clear what those posting flushes actually
achieve. Do they achieve IRQ disabling on completion? Hardly, IRQ can
use whole different channel anyway.
And, as for spinlock/IO ordering, libata currently depends on IO
instructions not leaking outside of spinlock (ordering-wise). We have
posting flushes at several places and some of them clearly make sense
(e.g. timed wait) but some others aren't that clear while majority of
places just don't do anything about ordering other than wrapping them
inside spinlock.
So, I don't really know. Do we have to add mmiowb() before every
spin_unlock after IO? Or, do we have to do explicit flushes everytime?
Or, is it something to be taken care of in the upper layer?
--
tejun
-
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