lkml.org 
[lkml]   [2001]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86 ptep_get_and_clear question
Jamie Lokier wrote:
>
> Manfred Spraul wrote:
> > The other cpu writes the dirty bit - we just overwrite it ;-)
> > After the ptep_get_and_clear(), before the set_pte().
>
> Ah, I see. The other CPU does an atomic *pte |= _PAGE_DIRTY, without
> checking the present bit. ('scuse me for temporary brain failure).
>
> How about a pragmatic solution.
>
Ok, Is there one case were your pragmatic solutions is vastly faster?

* mprotect: No. The difference is at most one additional locked
instruction for each pte.

* munmap(anon): No. We must handle delayed accessed anyway (don't call
free_pages_ok() until flush_tlb_ipi returned). The difference is that we
might have to perform a second pass to clear any spurious 0x40 bits.

* munmap(file): No. Second pass required for correct msync behaviour.

* try_to_swap_out(): No. another memory read.

Any other cases?
>
> Ben, fancy writing a boot-time test?
>
I'd never rely on such a test - what if the cpu checks in 99% of the
cases, but doesn't handle some cases ('rep movd, everything unaligned,
...'. And check the Pentium III erratas. There is one with the tlb
that's only triggered if 4 instruction lie in a certain window and all
access memory in the same way of the tlb (EFLAGS incorrect if 'andl
mask,<memory_addr>' causes page fault)).

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

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.098 / U:2.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site