lkml.org 
[lkml]   [2008]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH UPDATE] x86: ignore spurious faults
Nick Piggin wrote:
> On Friday 25 January 2008 06:21, Jeremy Fitzhardinge wrote:
>
>> Matt Mackall wrote:
>>
>>> There's perhaps an opportunity to do this lazy TLB trick in the mmap
>>> path as well, where RW mappings are initially mapped as RO so we can
>>> catch processes dirtying them and then switched to RW. If the mapping is
>>> shared across threads on multiple cores, we can defer synchronizing the
>>> TLBs on the others.
>>>
>> I think spurious usermode faults are already dealt with.
>> handle_pte_fault() does essentially the same thing as this patch:
>>
>> if (ptep_set_access_flags(vma, address, pte, entry, write_access)) {
>> update_mmu_cache(vma, address, entry);
>> } else {
>> /*
>> * This is needed only for protection faults but the arch code
>> * is not yet telling us if this is a protection fault or not.
>> * This still avoids useless tlb flushes for .text page faults
>> * with threads.
>> */
>> if (write_access)
>> flush_tlb_page(vma, address);
>> }
>>
>
> I (obviously) don't know exactly how the TLB works in x86, but I
> thought that on a miss, the CPU walks the pagetables first before
> faulting? Maybe that's not the case if there is an RO entry
> actually in the TLB?
>

My understanding is that it will fault immediately if there's a TLB
entry, and rewalk the tables on return from the fault before restarting
the instruction, so there's no need for an explicit TLB flush. The TLB
doesn't have a notion of negative cache entries, so any entry represents
a present page of some variety.

J


\
 
 \ /
  Last update: 2008-01-25 01:29    [W:0.096 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site