On Wed, 11 Oct 2000, Linus Torvalds wrote:
>
> On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote:
> >
> > Note the fragment above those portions of the patch where the
> > pte_xchg_clear is done on the page table: this results in a page fault
> > for any other cpu that looks at the pte while it
On Thu, 12 Oct 2000, Ingo Molnar wrote:
> [...] pgd_clear() should stay a 64-bit operation [...]
even this isnt strictly necessery - pgds and pmds are allocated in 'low
memory', and thus a simple 32-bit write to the lower 32 bits of the pgd
entry is enough to clear a PAE pgd. But it still must
On Thu, 12 Oct 2000, David S. Miller wrote:
>clear neither user-space pgds, nor user-space pmds in PAE mode
>
> Eh?
>
> munmap() --> clear_page_tables() --> free_one_pgd() --> pgd_clear
you are right, i was focused too much on the swapping case. I dont think
munmap() is a problem in the P
Date:Thu, 12 Oct 2000 10:13:48 +0200 (CEST)
From: Ingo Molnar <[EMAIL PROTECTED]>
the PAE pgd 'anomaly' should not affect this case, because we never
clear neither user-space pgds, nor user-space pmds in PAE mode
Eh?
munmap() --> clear_page_tables() --> free_one_pgd() --> pg
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> (Instead of doing an atomic 64-bit memory write, we would be doing the
> atomic "pte_xchg_clear()" followed by two _non_atomic 32-bit writes where
> the second write would set the present bit. Although maybe the erratum
> about the PAE pgd entry not h
On Thu, 12 Oct 2000, Benjamin C.R. LaHaise wrote:
>
> Note the fragment above those portions of the patch where the
> pte_xchg_clear is done on the page table: this results in a page fault
> for any other cpu that looks at the pte while it is unavailable.
Ok, I see..
Hmm.. That's a singularly
On Wed, 11 Oct 2000, David S. Miller wrote:
>It's safe because of how x86s hardware works
>
> What about other platforms?
If atomic ops don't work, then software dirty bits are still an option
(read as: it shouldn't break RISC CPUs).
-ben
-
To unsubscribe from this list: s
}Date: Thu, 12 Oct 2000 00:03:31 -0400 (EDT)
}From: "Benjamin C.R. LaHaise" <[EMAIL PROTECTED]>
}
}It's safe because of how x86s hardware works
}
} What about other platforms?
On the PPC's that don't do a hardware walk we do a normal write to the
hash table (with a spinlock).
Date:Thu, 12 Oct 2000 00:03:31 -0400 (EDT)
From: "Benjamin C.R. LaHaise" <[EMAIL PROTECTED]>
It's safe because of how x86s hardware works
What about other platforms?
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Hello Linus,
On Wed, 11 Oct 2000, Linus Torvalds wrote:
> I much prefered the dirty fault version.
> What does "quite noticeable" mean? Does it mean that you can see page
> faults (no big deal), or does it mean that you can actually measure the
> performance degradation objectively?
It's a fac
On Wed, 11 Oct 2000, Ben LaHaise wrote:
>
> Here's an updated version of the patch that doesn't do the funky RISC like
> dirty bit updates. It doesn't incur the additional overhead of page
> faults on dirty, which actually happens a lot on SHM attaches
> (during Oracle runs this is quite notic
On Wed, 11 Oct 2000 [EMAIL PROTECTED] wrote:
>> 2. Capable Of Corrupting Your FS/data
>>
>> * Non-atomic page-map operations can cause loss of dirty bit on
>>pages (sct, alan)
>
>Is anybody looking into fixing this bug ?
>
> According to sct (who's sitting next
12 matches
Mail list logo
