Date: Sun, 22 Dec 1996 17:18:36 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: smp@freebsd.org Subject: Re: P6 problem idea Message-ID: <199612222218.RAA00490@dyson.iquest.net> In-Reply-To: <26009.851291582@critter.tfs.com> from "Poul-Henning Kamp" at Dec 22, 96 10:53:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >If you want to test that -- all you have to do is to disable the > >setting of PG_G in locore and in pmap. You can also optionally > >turn off the capability (but you still need to disable all of the > >PG_G bit setting) by not setting the CR4_PGE bit in cr4 also. > > > >This *could* be the problem, because you need to do the single page > >updates when the PG_G bit has been set (or there are more complex ways > >of doing it also.) The global update will just not work... (Of course, > >that is much of the purpose of the PG_G bit :-)). > > Well, we might have to be more selective about what we "Globalize" then... > Only in the SMP case. The kernel itself (the image) is pretty safe, and there is quite alot of the bang to be gotten just for that. I think that it is OK to tradeoff a little in performance on an SMP kernel. In the single-processor kernel, the biggest thing that we currently cannot take advantage of mapping into the kernel permanently are the UPAGES and associated kernel stack. When we make the kernel stack more mobile, we'll even be able to take advantage of the PG_G flag for that. I still think that we should also take advantage of the 4M pages, but that is still probably in the future (except for perhaps mapping in the frame-buffer.) Sure wish those 4M pages were 256K or so, we could use them much more effectively. So, after all of my rambling, it is probably safe to keep the PG_G flag being set in locore at startup time (esp. for the kernel .text), but it might be too complex to use in SMP case where the mappings are more dynamic. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612222218.RAA00490>