Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Aug 2001 01:49:00 -0700
From:      Peter Wemm <peter@wemm.org>
To:        tlambert2@mindspring.com
Cc:        Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>, arch@FreeBSD.ORG, audit@FreeBSD.ORG, kumabu@t3.rim.or.jp
Subject:   Re: CFR: Timing to enable CR4.PGE bit 
Message-ID:  <20010822084900.4306738FD@overcee.netplex.com.au>
In-Reply-To: <3B836737.9C15EA8@mindspring.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:

[the other part]

> To me, it seems that this will load the PGE bit enabled
> entries for the 4K pages into core exceptionally early, and
> that doing this will conflict with the later 4M page entry,
> which will end up having its own mapping (since 4M pages have
> their own, seperate table), and thus I will end up with two
> mappings for the same pages, neither of which can be easily
> invalidated on a P3 or P4 without toggling PGE off first,
> since they all have the PG_G bit set in them.

While this is true, we do not change the wiring of the text+data+bss
virtual -> physical pages that are double-mapped when we round up to the
4MB boundary.  (see pmap_choose_addr() for the roundup)

While they should never conflict and are never changed, I could imagine
that having 4K and 4MB tlb's matching on the same virtual address could
possibly cause some odd behavior, I'm a little doubtful.  I would have
expected it to turn up on other cpu brands (eg: athlon, transmeta etc)
by now.

> I can tell you from personal experience on a Tyan Tiger
> with 1G of RAM and on a Super Micro with 4G of RAM that
> this can lead to very bad problems, unless you have enough
> entries being made in the KVA space to cause the invalidations
> to LRU out the pages... specifically, I saw some very
> interesting faults with mbufs, until I grew some kernel
> structures large enough to force the shootdown during the
> normal boot process, and it wasn't until later that I
> recognized the origin of the problem.

It would be cleaner to make a decision once in pmap_bootstrap() that went
through and flipped PG_G on either the the 4MB page or the underlying 4K
pages.  That way there would be no possible overlapping PG_G tlb entries.

> It used to be that you could just reload CR3 with the same
> value to force an invalidation of pages without PG_G set
> with PGE enabled, or with PG_G set, without PGE enabled,
> but that's no longer true on newer systems, which will
> forego the invalidation if you are reloading the same value
> (for obvious performance reasons).

I dont think we did this anyway.  Once set, PG_G and PGE stayed set
forever.

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-audit" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010822084900.4306738FD>