Rik van Riel wrote:
> > The person writing and updating page table entries in NetWare
> > 4.1 was clearing the accessed bit in the PTE and did not know
> > that the processor would assert a hidden R/M/W operation and
> > assert a bus lock to set this bit everytime someone cleared it
> > -- it made performance drop 4% from NetWare 3.X and noone knew
> > why.
>
> Hmmm, this sounds like an `interesting' incident that we need
> to know more about. Currently Linux may have some problems with
> the PTE modifying code so if you have any details about how
> exactly you are supposed to modify a PTE, we'd like to know ;)
It's not related to the races.
When the x86 sets the Accessed bit in a page table (due to an access ;-)
or the Dirty bit (due to writing), it does a LOCKed read-modify-write
cycle to update the bit in the page table.
This locked cycle is only done when the bit actually needs to be update.
(To be honest I thought it always did a locked cycle although it's
obviously better not to).
Locked cycles have a certain cost as you know, so if possible avoid
them. This means if you don't need to monitor Accessed or Dirty, set
the bits you're not interested in when you initialise the pte.
Linux does actually look at both bits. However, quite often a pte is
set up in response to a page fault. Then you _know_ the page is about
to be accessed so it's worth setting Accessed. If it's a write fault,
you're pretty confident it's going to be dirtied too so may as well set
Dirty.
Amazingly (doesn't Jeff read any of our code?), Linux implements both
these optimisations and has done as far back as I remember looking at
the source. That would be about 6 years, 1.0.x days. I don't think a
debugger was used ;-)
1. Accessed: See def. of PAGE_* in <asm-i386/pgtable.h>.
_PAGE_ACCESSED is set on all new ptes by default.
2. Dirty: See comment "This silly early PAGE_DIRTY setting removes a
race due to the bad i386 page protection..." in memory.c. I don't
see the race but I do see it as an optimisation :-)
have a nice day,
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:15 EST