Re: [RFC] atomic pte updates and pae changes, take 2
On Fri, 13 Oct 2000, Linus Torvalds wrote: > Ingo, I'd like you to comment on all the PAE issues just in case, but > I personally don't have any real issues any more. [...] there is one small thing apart of the issue Stephen noticed, barrier() between the two 32-bit writes should IMO be smp_wmb() instead. It should not make any difference on current x86 CPUs, but if any future x86 SMP implementation relaxes memory ordering, it will be easier to sort things out. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
On Sat, 14 Oct 2000, Stephen Tweedie wrote: > Looks good. The only trouble I can see left is that pte_clear() is > still using set_pte(), which doesn't work right for PAE36. set_pte() > is setting the high word first, which is fine for installing a new > pte, but if you do that to clear a pte then you have left the old > page-present bit intact while you've removed have of the pte. > pte_clear() needs to clear the words in the other order (just as > pte_get_and_clear correctly does). yep, that should make it work. The pgd operations must use 64-bit instructions - the pmds are fine to be 64-bit for the time being, but they can be changed to the pte logic as well. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
Hi, On Fri, Oct 13, 2000 at 08:17:42PM -0400, Ben LaHaise wrote: > > Below is take two of the patch making pte_clear use atomic xchg in an > effort to avoid the loss of dirty bits. PAE no longer uses cmpxchg8 for > updates; set_pte is two ordered long writes with a barrier. Looks good. The only trouble I can see left is that pte_clear() is still using set_pte(), which doesn't work right for PAE36. set_pte() is setting the high word first, which is fine for installing a new pte, but if you do that to clear a pte then you have left the old page-present bit intact while you've removed have of the pte. pte_clear() needs to clear the words in the other order (just as pte_get_and_clear correctly does). Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
Date:Fri, 13 Oct 2000 18:43:47 -0700 (PDT) From: Linus Torvalds <[EMAIL PROTECTED]> I dislike the "__HAVE_ARCH_xxx" approach, and considering that most architectures will probably want to do something specific anyway I wonder if we should get rid of that and just make architectures have their own code. Most software-based TLB refill systems could (and sparc64 will) make all ref/mod bit updates occur in the kernel software fault path so that none of this special synchronization is necessary. In such cases it might be nice to have a generic version that all such ports can share by just not defining __HAVE_ARCH_xxx. Sure it's a bit ugly, but it does allow code sharing, so it probably at least deserves a chance :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
Date:Fri, 13 Oct 2000 18:43:47 -0700 (PDT) From: Linus Torvalds [EMAIL PROTECTED] I dislike the "__HAVE_ARCH_xxx" approach, and considering that most architectures will probably want to do something specific anyway I wonder if we should get rid of that and just make architectures have their own code. Most software-based TLB refill systems could (and sparc64 will) make all ref/mod bit updates occur in the kernel software fault path so that none of this special synchronization is necessary. In such cases it might be nice to have a generic version that all such ports can share by just not defining __HAVE_ARCH_xxx. Sure it's a bit ugly, but it does allow code sharing, so it probably at least deserves a chance :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
Hi, On Fri, Oct 13, 2000 at 08:17:42PM -0400, Ben LaHaise wrote: Below is take two of the patch making pte_clear use atomic xchg in an effort to avoid the loss of dirty bits. PAE no longer uses cmpxchg8 for updates; set_pte is two ordered long writes with a barrier. Looks good. The only trouble I can see left is that pte_clear() is still using set_pte(), which doesn't work right for PAE36. set_pte() is setting the high word first, which is fine for installing a new pte, but if you do that to clear a pte then you have left the old page-present bit intact while you've removed have of the pte. pte_clear() needs to clear the words in the other order (just as pte_get_and_clear correctly does). Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
On Fri, 13 Oct 2000, Ben LaHaise wrote: > > Hey folks Me likee. This looks much nicer. The hack turned into something that looks quite ddesigned. Ingo, I'd like you to comment on all the PAE issues just in case, but I personally don't have any real issues any more. Small nit: I dislike the "__HAVE_ARCH_xxx" approach, and considering that most architectures will probably want to do something specific anyway I wonder if we should get rid of that and just make architectures have their own code. Thanks, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] atomic pte updates and pae changes, take 2
On Fri, 13 Oct 2000, Ben LaHaise wrote: Hey folks Me likee. This looks much nicer. The hack turned into something that looks quite ddesigned. Ingo, I'd like you to comment on all the PAE issues just in case, but I personally don't have any real issues any more. Small nit: I dislike the "__HAVE_ARCH_xxx" approach, and considering that most architectures will probably want to do something specific anyway I wonder if we should get rid of that and just make architectures have their own code. Thanks, Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
