On Thu, 3 Mar 2005, Benjamin Herrenschmidt wrote: > > There is no need to provide pte_cmpxchg. If the arch does not support > > cmpxchg on ptes (CONFIG_ATOMIC_TABLE_OPS not defined) > > then it will fall back to using pte_get_and_clear while holding the > > page_table_lock to insure that the entry is not touched while performing > > the comparison. > > Nah, this is wrong :) > > We actually _want_ pte_cmpxchg on ppc64, because we can do the stuff, > but it requires some careful manipulation of some bits in the PTE that > are beyond linux common layer understanding :) Like the BUSY bit which > is a lock bit for arbitrating with the hash fault handler for example. > > Also, if it's ever used to cmpxchg from anything but a !present PTE, it > will need additional massaging (like the COW case where we just > "replace" a PTE with set_pte). We also need to preserve some bits in > there that indicate if the PTE was in the hash table and where in the > hash so we can flush it afterward.
You can define your own pte_cmpxchg without a problem ... - 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/
