I'm not entirely convinced.
Some architectures simply aren't good at doing bitwise locking, and we may
have to change the current "pte_chain_lock()" to a different
implementation.
In particular, with the current pte_chain_lock() interface, it will be
_trivial_ to turn that bit in page->flags to be instead a hash based on
the page address into an array of spinlocks. Which is a lot more portable
than the current code.
(The current code works, but look at what it generates on old sparcs, for
example).
Your patch, while it cleans up some things, makes it a lot harder to do
those kinds of changes later.
So I would suggest (at least for now) to _not_ get rid of the
pte_chain_lock() abstraction, and re-doing your patch with that in mind.
Gettign rid of the (unnecessary) UP locking is good, but getting rid of
the abstraction doesn't look like a wonderful idea to me.
Linus
-
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/