On Wed, 11 Oct 2000, Linus Torvalds wrote:
>
> On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote:
> >
> > Note the fragment above those portions of the patch where the
> > pte_xchg_clear is done on the page table: this results in a page fault
> > for any other cpu that looks at the pte while it is unavailable.
>
> Ok, I see..
>
> Hmm.. That's a singularly ugly interface, though - it all looks very
> x86-specific. Things like "pte_xchg_clear()" look just a bit too obviously
> like the name only makes sense due to the x86 implementation. So I'd like
> to change the naming to be more about the design and less about the
> implementation..
How about pte_get_and_clear?
> (It also doesn't make sense to me that you call the "clear the write bit"
> thing "atomic_pte_wrprotect()", but you call the "clear the dirty bit"
> "pte_test_and_clear_dirty()" - why not the same naming scheme for the two
> things?).
*nod*
> I also have this suspicion that if this was done right, we should be able
> to clean up the 64-bit atomic stuff for the x86 PAE case - which does a
> cmpxchg8b right now on PAE entries exactly because of atomicity reasons.
>
> With your patch as it stands now, we'd end up basically always doing two
> of them.
>
> And looking at the patch I get this nagging feeling that if this was
> really done right, we could get rid of that PAE special case for
> set_pte(), because the issue with atomic updates on PAE really boils down
> to pretty much the same thing as the issue of one atomic bit.
> (Instead of doing an atomic 64-bit memory write, we would be doing the
> atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where
> the second write would set the present bit. Although maybe the erratum
> about the PAE pgd entry not honoring the P bit correctly makes this be
> unworkable).
As Ingo pointed out, this is only a problem for the pgd; we're safe so
long as atomic operations are used on the present bit for pte's. I think
we can completely eliminate the cmpxchg8b for ptes by using xchg on the
low byte containing the P bit and non atomic ops on the high byte. This
should be much better!
...
> What do you say, Ben? Do you think your approach really would solve the
> PAE atomicity issue too, or am I just expecting too much?
These are good ideas. I'll go back and rework the patch for PAE stuff and
see what kind of results turn out.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:23 EST