Re: page table lock patch V15 [0/7]: overview

From: Christoph Lameter (clameter_at_sgi.com)
Date: 01/13/05

  • Next message: Randy.Dunlap: "Re: ieee1394 errors on attempted insmod" 
    Date:	Wed, 12 Jan 2005 16:16:43 -0800 (PST)
To: Nick Piggin <nickpiggin@yahoo.com.au>

    On Thu, 13 Jan 2005, Nick Piggin wrote:

    > > Pointer operations and word size operations are atomic. So this is mostly
    > > okay.
    > >
    > > The issue arises on architectures that have a large pte size than the
    > > wordsize. This is only on i386 PAE mode and S/390. S/390 falls back to
    > > the page table lock for these operations. PAE mode should do the same and
    > > not use atomic ops if they cannot be made to work in a reasonable manner.
    > >
    >
    > Yep well you should be OK then. Your implementation has the advantage
    > that it only instantiates previously clear ptes... hmm, no I'm wrong,
    > your ptep_set_access_flags path modifies an existing pte. I think this
    > can cause subtle races in copy_page_range, and maybe other places,
    > can't it?

    ptep_set_access_flags is only used after acquiring the page_table_lock and
    does not clear a pte. That is safe. The only critical thing is if a pte
    would be cleared while holding the page_table_lock. That used to occur in
    the swapper code but we modified that.

    There is still an issue as Hugh rightly observed. One cannot rely on a
    read of a pte/pud/pmd being atomic if the pte is > word size. This occurs
    for all higher levels in handle_mm_fault. Thus we would need to either
    acuire the page_table_lock for some architectures or provide primitives
    get_pgd, get_pud etc that take the page_table_lock on PAE mode. ARGH.

    -
    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/

  • Next message: Randy.Dunlap: "Re: ieee1394 errors on attempted insmod"

    Relevant Pages

    • Re: Page fault scalability patch V18: Drop first acquisition of ptl
      ... It relies upon page_table_lock for pte atomicity. ... >> architectures then they have no solution to the scalability problem. ... > corner and I have reworked the patches numerous times. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • RE: Hugetlb demanding paging for -mm tree
      ... >> translation to be established in many architectures. ... > type of pte and do appropriate sizing and other things. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [patch 2.6.13-rc4] fix get_user_pages bug
      ... > Or should we change s390 to set a flag in the pte just for this purpose? ... architectures except s390 handle_pte_faultwill then create a pte with ... With the physical dirty bit patch pte_dirtyis ... 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/ ...
      (Linux-Kernel)
    • Re: page table lock patch V15 [0/7]: overview
      ... >>Note that this was with my ptl removal patches. ... > not use atomic ops if they cannot be made to work in a reasonable manner. ... your ptep_set_access_flags path modifies an existing pte. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2/3] powerpc ioremap_prot
      ... This was just a patch to "make it work" so Rik could move ... on with his core patch (btw. Rik, you got the SOBs in the wrong order on ... architectures, ... +static inline unsigned long pte_pgprot(pte_t pte) { ...
      (Linux-Kernel)