On Thu, May 08, 2003 at 02:43:15PM -0500, Alan L. Cox wrote: > For the record, this is not completely correct. DISABLE_PSE does > control the use of 4MB pages. DISABLE_PG_G is, however, something > entirely different. Normally, on a process context switch TLB entries > for the old address space are flushed. If a TLB entry corresponds to an > in-kernel virtual-to-physical mapping, there is no reason to flush that > entry because all processes share the same kernel address space. > Setting the "G"lobal bit on a page table entry accomplishes this. In > other words, the TLB entry persists across context switches. > DISABLE_PG_G disables this. > > The problem with PG_G is that the "flush all" TLB entries operation, > just like a context switch, has no effect on entries marked as global. > Such entries have to be flushed by specifying their address in a "flush > single page" operation. Sometimes the failure to flush an entry is > covered up by a combination of DISABLE_PG_G and a lucky context switch. > > So, in summary, it does make sense to try these options separately. This is not my expertise, so take me with a grain of salt :) I think Terry also already mentioned this. PSE for the 4M pages and PG_G for the global pages. I also think that last time we concluded that they are both needed. He mentioned I guess that while using only one of them might "solve" the problem, but that would only be hiding the problem for a bit longer. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTMReceived on Thu May 08 2003 - 10:52:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC