Messages in this thread | | | Date | 4 Jan 2005 21:21:04 +0100 | Date | Tue, 4 Jan 2005 21:21:04 +0100 | From | Andi Kleen <> | Subject | Re: page fault scalability patch V14 [5/7]: x86_64 atomic pte operations |
| |
On Tue, Jan 04, 2005 at 11:58:13AM -0800, Christoph Lameter wrote: > On Tue, 4 Jan 2005, Andi Kleen wrote: > > > Christoph Lameter <clameter@sgi.com> writes: > > > > I bet this has been never tested. > > I tested this back in October and it worked fine. Would you be able to > test your proposed modifications and send me a patch?
Hmm, I don't think it could have worked this way, except if you only tested page faults < 4GB.
> > > > +#define pmd_test_and_populate(mm, pmd, pte) \ > > > + (cmpxchg((int *)pmd, PMD_NONE, _PAGE_TABLE | __pa(pte)) == PMD_NONE) > > > +#define pud_test_and_populate(mm, pud, pmd) \ > > > + (cmpxchg((int *)pgd, PUD_NONE, _PAGE_TABLE | __pa(pmd)) == PUD_NONE) > > > +#define pgd_test_and_populate(mm, pgd, pud) \ > > > + (cmpxchg((int *)pgd, PGD_NONE, _PAGE_TABLE | __pa(pud)) == PGD_NONE) > > > + > > > > Shouldn't this all be (long *)pmd ? page table entries on x86-64 are 64bit. > > Also why do you cast at all? i think the macro should handle an arbitary > > pointer. > > The macro checks for the size of the pointer and then generates the > appropriate cmpxchg instruction. pgd_t is a struct which may be > problematic for the cmpxchg macros.
It just checks sizeof, that should be fine.
-Andi
- 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/
| |