Date: Wed, 14 May 2003 08:50:21 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Heiko Schaefer <hschaefer@fto.de> Subject: Re: 5.1-RELEASE TODO Message-ID: <3EC265BD.9B9FEFAC@mindspring.com> References: <XFMail.20030514102537.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On 14-May-2003 Terry Lambert wrote: > > The DISABLE_PG_G, as I said in a previous posting, works around > > an order of operation problem that needs to clear PG in %CR0 > > while it does it's thing, after which there's no problem with > > enabling it. See "IA-32 Intel Architecture Software Developer's > > Manual, Volume 3: System Programming Guide for more details on > > PG_G, the PG bit in %CR0, and the effect on TLB flushing; look > > specifically at Section 10.9 of "Memory Cache Control", which is > > entitled "Invalidating The TRanslation Lookaside Buffers". > > > > Specifically, writing %CR3 doesn't invalidate pages with PG_G > > set on them if PG is set in %CR0. > > Umm, Terry, that's the whole point of PGE. You don't flush entries > from the TLB that are "global", i.e. shared among all processes and > don't change. "Duh". Basically your suggestion would be an > expensive hack equivalent to DISABLE_PG_G. No. My suggestion would be to not load something into a global page before some of the VM system mappings have been established. Basically, there is some machdep.c code that's out of order. Reordering it is hard, so I haven't done it yet. In other words, the problem is that someone is enabling PG in %CR0 way too early. Read the first sentence again: "...works around an order of operation problem...". I think if you check the archives back to when I first started recommending that both DISABLE_PSE and DISABLE_PG_G be used, rather than just DISABLE_PSE, it comes down to the machdep.c and locore.s reorganization, where I complained that the new order of operation had problems. This happened back before the 5.0 DP1. My suggestion then was "revert the changes"; barring that, someone is going to have to sit down and go through the new code, like I went through the old code, and understand where every byte of memory is coming from, and how and when it gets into the memory map. I personally think this is probably the responsibility of the people who changed the code and broke use of PG in the first place. -- Terry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EC265BD.9B9FEFAC>