[lkml]   [2001]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: x86 ptep_get_and_clear question

    On Fri, 16 Feb 2001, Manfred Spraul wrote:

    > Jamie Lokier wrote:
    > >
    > > Linus Torvalds wrote:
    > > > So the only case that ends up being fairly heavy may be a case that is
    > > > very uncommon in practice (only for unmapping shared mappings in
    > > > threaded programs or the lazy TLB case).
    > >
    > The lazy tlb case is quite fast: lazy tlb thread never write to user
    > space pages, we don't need to protect the dirty bits. And the first ipi
    > clears mm->cpu_vm_mask, only one ipi.

    This is NOT necessarily true in the generic case.

    The lazy TLB thread itself may not write to the address space, but I can
    in theory see a hardware implementation that delays writing out the dirty
    bit from the TLB until it is invalidated. I agree that it is unlikely,
    especially on an x86, but I think it's a case we should at least think
    about for the generic kernel architecture.

    Think of the TLB as a cache, and think of the dirty state as being either
    write-through or write-back. Now, I will bet you that all current x86's
    (a) _do_ actually check the P bit when writing D (ie current Linux code
    is probably fine as-is, even if incorrect in theory)
    (b) the D bit is write-through.

    But even so, I want people to at least consider the case of a write-back
    TLB dirty bit, in which case the real state of the D bit might not be
    known until a TLB flush has been done (even on a UP machine - which is why
    I'm certain that no current x86 actually does this optimization).

    (And because of (a), I don't think I'll necessarily fix this during 2.4.x
    anyway unless it gets fixed as a result of the generic TLB shootdown issue
    which has nothing at all to do with the D bit)

    Don't get too hung up on implementation details when designing a good
    architecture for this thing.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:15    [W:0.042 / U:1.260 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site