lkml.org 
[lkml]   [2002]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: readl/writel and memory barriers
On Tue, Feb 19, 2002 at 11:33:22AM -0800, David Mosberger wrote:
> It certainly does for on ia64-compliant system. Check section 9.3
> "Multi-threaded Code" in the "Itanium Software Conventions and Runtime
> Architecture manual".

I don't have that doc handy, but I'll trust your judgement...

> Now, with NUMA platforms, where the chipsets/switch may re-order
> accesses, the performance hit will be much bigger, so the old scheme
> may not be sufficient.

Right. I still have to do some performance measurements, but I
suspect that as the system size goes up, we'll see the I/O ordering
penalty increase. It'll probably get noticable at around 64p.

> I'm no NUMA expert, but my guess is that nobody will want to go
> through all the existing drivers to change them to use mmiob(). For
> new drivers, it might be OK.

The source level impact should actually be pretty small. An mmiob()
prior to the spin_unlock in a critical section that does I/O usually
suffices. Maybe it would be a good idea to have io_spin_lock and
io_spin_unlock for this purpose?

Thanks,
Jesse
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:24    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site