Messages in this thread | | | Date | Wed, 1 Sep 2004 09:43:54 -0700 (PDT) | From | Christoph Lameter <> | Subject | Re: page fault scalability patch final : i386 tested, x86_64 support added |
| |
On Wed, 1 Sep 2004, Benjamin Herrenschmidt wrote:
> The removal of the page table lock has other more subtle side effects > on ppc64 (and ppc32 too) that aren't trivial to solve. Typically, due > to the way we use the hash table as a TLB cache. > > For example, out ptep_test_and_clear will first clear the PTE and then > flush the hash table entry. If in the meantime another CPU gets in, > takes a fault, re-populates the PTE and fills the hash table via > update_mmu_cache, we may end up with 2 hash PTEs for the same linux > PTE at least for a short while. This is a potential cause of checkstop > on ppc CPUs. > > There may be other subtle races of that sort I haven't encovered yet. > > We need to spend more time on our (ppc/ppc64) side to figure out what > is the extent of the problem. We may have a cheap way to fix most of the > issues using the PAGE_BUSY bit we have in the PTEs as a lock, but we > don't have that facility on ppc32. > > I think there wouldn't be a problem if we could guarantee exclusion > between page fault and clearing of a PTE (that is basically having the > swapper take the mm write sem) but I don't think that's realistic, oh > well, not that I understand anything about the swap code anyways...
We may be able to accomplish that by generic routines for ptep_cmpxchg and so on that would use the page table lock for platforms that do not support atomic pte operations.
Something along the lines of:
pte_t ptep_xchg(struct mm_struct *mm, pte_t *ptep, pte_t new) { pte_t old;
spin_lock(&mm->page_table_lock); old = *ptep set_pte(ptep, new_pte); /* Do rehashing */ spin_unlock(&mm->page_table_lock); return old; }
This would limit the time that the page_table_lock is held to a minimum and may still offer some of the performance improvements.
Would that be acceptable? - 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/
| |