> I think that's a separate issue? As Jeff points out, those macros are
> intended to provide memory vs. I/O ordering, but isn't PPC the only platform
> that will reorder accesses so aggressively and independently? I don't think
> ia64 for example will reorder them separately, so a regular memory barrier
> *should* be enough to ensure ordering in both domains.
Well, I don't know, that's what I'm asking since the comment in the
driver specifically mentions IA64 :)
> > Hence the question: do we provide -fully- ordered accessors in class 1,
> > or do we provide -mostly- ordered accessors, ordered in all means except
> > rule #4 vs locks. ia64 is afaik by far the platform taking the biggest
> > hit if you have to provide #4, so I'm interesting in your point of view
> > here.
>
> Either way is fine with me as long as we have a way to get at the fast and
> loose stuff (and required barriers of course) in a portable way. And that we
> don't regress the existing users of mmiowb().
Well, existing users of mmiowb() will regress in performances if we
decide that class 1 (ordered) accessors do imply rule #4 (ordering with
locks) since they'll end up doing redundant mmiowb's ;) but then,
they'll be affected anyway to to the sheer amount of mmiowb's (one per
IO) unless you implement the trick I described, which would bring down
the cost to nothing except maybe the test in spin_unlock (which I still
need to measure on PowerPC).
> > We don't need counters, just a flag. We did a test implementation, seems
> > to work. We also clear the flag in spin_lock. That means that MMIOs
> > issued before a lock aren't ordered vs. the locked section. But because
> > of rule #1, they should be ordered vs. other MMIOs inside the locked
> > section and thus implicitely get ordered anyway.
>
> Oh right, a flag would be enough. Is it good enough for -mm yet? Might be
> fun to run on an Altix machine with a bunch of supported devices (not that I
> work with them anymore...).
The PowerPC patch is probably good enough for 2.6.18 in fact :) I'll let
Paulus post what he has. It's fairly ppc specific in the actual
implementation though.
> > > For ia64 in particular it doesn't matter, though there was speculation
> > > several years that it might be necessary. No actual examples stepped
> > > forward though, so the current implementation doesn't take an argument.
> >
> > Ok. My question is wether it would improve the implementation to take
> > it. If we define a new macro with a new name, we can do it....
>
> Right, but unless there's a real need at this point, we probably shouldn't
> bother. Let the poor sucker with the future machine needing the device
> argument do the work. :)
Ok :)
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
