Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Mar 2005, Andrew Morton wrote: > > > > - if (!PageReserved(old_page)) > > > - page_cache_get(old_page); > > > > hm, this seems to be an unrelated change. You're saying that this page is > > protected from munmap() by munmap()'s down_write(mmap_sem), yes? What > > stops memory reclaim from freeing old_page? > > This is a related change discussed during V16 with Nick.
It's worth retaining a paragraph for the changelog. > The page is protected from munmap because of the down_read(mmap_sem) in > the arch specific code before calling handle_mm_fault. We don't take mmap_sem during page reclaim. What prevents the page from being freed by, say, kswapd? > > > - mark_page_accessed(page); > > > + SetPageReferenced(page); > > > > Another unrelated change. IIRC, this is indeed equivalent, but I forget > > why. Care to remind me? > > Seems that mark_page_accessed was discouraged in favor SetPageReferenced. > We agreed that we wanted this change earlier (I believe that was in > November?). I forget. I do recall that we decided that the change was OK, but briefly looking at it now, it seems that we'll fail to move a PageReferenced,!PageActive onto the active list? > > Overall, do we know which architectures are capable of using this feature? > > Would ppc64 (and sparc64?) still have a problem with page_table_lock no > > longer protecting their internals? > > That is up to the arch maintainers. Add something to arch/xx/Kconfig to > allow atomic operations for an arch. Out of the box it only works for > x86_64, ia64 and ia32. Feedback from s390, sparc64 and ppc64 people would help in making a merge decision. > > I'd really like to see other architecture maintainers stand up and say > > "yes, we need this". > > You definitely need this for machines with high SMP counts. Well. We need some solution to the page_table_lock problem on high SMP counts. > > Did you consider doing the locking at the pte page level? That could be > > neater than all those games with atomic pte operattions. > > Earlier releases back in September 2004 had some pte locking code (and > AFAIK Nick also played around with pte locking) but that > was less efficient than atomic operations. How much less efficient? Does anyone else have that code around? - 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/
