On Thu, 22 Dec 2005, Linus Torvalds wrote:
> On Thu, 22 Dec 2005, Nicolas Pitre wrote:
>
> > On Thu, 22 Dec 2005, Ingo Molnar wrote:
> >
> > > Changes since -V4:
> > >
> > > - removed __ARCH_WANT_XCHG_BASED_ATOMICS and implemented
> > > CONFIG_MUTEX_XCHG_ALGORITHM instead, based on comments from
> > > Christoph Hellwig.
> > >
> > > - updated ARM to use CONFIG_MUTEX_XCHG_ALGORITHM.
> >
> > This is still not what I'd like to see, per my previous comments.
> >
> > Do you have any strong reason for pursuing that route instead of going
> > with my suggested approach?
>
> I'd just prefer a
>
> <asm-generic/mutex-xchg-algo.h>
>
> and then any architecture can do whatever they damn well want, and
> anybody who doesn't want to, can just include that header file.
>
> No #ifdef's, no config options, no "generic fallback". Just
> unconditionally do the sane thing.
>
> I'm with whoever HATES those stupid __ARCH_xxx #defines. It's a sign of
> bad design. Either it's a generic algorithm (and it can be in
> <asm-generic> or it's not). In no case should we ever have __ARCH_HAS_xxx
> (and yes, that includes cases where we _currently_ use __ARCH_HAS_xxx).
Isnt there some other way to make all of this much easier to modify? Both
the arch specific and the generic layers?
There are definitely arch specific improvements but there are also
possible ways that the generic way of locking can be improved. Some of
these may require changing the data structures.
F.e. I know a couple of architectures (embedded as well as different
varieties of NUMA) that have special memory areas for locks that bypass
the bus protocols in order to realize more efficient locking.
Large NUMA systems with lots of lock contention benefit if the one
trying to lock backs off for awhile. This is first of all a modification
of the contention path. However, one could also want to locally block
multiple lock attempts coming from the same node in order to reduce
contention on the NUMA interlink. See also my HBO proposal
http://marc.theaimsgroup.com/?l=linux-kernel&m=111696945030791&w=2
I would like some more flexible way of dealing with locks in general. The
code for the MUTEXes seems to lock us into a specific way of realizing
locks again.
-
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]
