Date: Thu, 17 Jun 2010 21:53:09 +0530 From: "Jayachandran C." <c.jayachandran@gmail.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-mips@freebsd.org Subject: Re: Merging 64 bit changes to -HEAD - part 2 Message-ID: <AANLkTimkF47RlysFOrma0YhWNDw2w5Lcp9SB1bBoPuxW@mail.gmail.com> In-Reply-To: <20100617.100235.195066307596264499.imp@bsdimp.com> References: <AANLkTimmIBz1sfRx8I8E0OhNQz8wEtBihr1YZ26QfYL0@mail.gmail.com> <98F8CB29-62FE-41A6-8AE6-6F8AF086D29C@lakerest.net> <20100617.100235.195066307596264499.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 17, 2010 at 9:32 PM, M. Warner Losh <imp@bsdimp.com> wrote: > In message: <98F8CB29-62FE-41A6-8AE6-6F8AF086D29C@lakerest.net> > =A0 =A0 =A0 =A0 =A0 =A0Randall Stewart <rrs@lakerest.net> writes: > : JC: > : > : I don't think renaming the PTE entries to PG_ is a good idea. > : > : Way back in 2007 this was one of the issues I hit.. the J code > : used PG_ and somewhere in the VM we used PG_ to indicate (Page). > : > : Thus we ended up with a PG_G defined in two places and we were setting > : PG_G and it was Not the PTE PG_G.. but the one defined in the VM. > > This was a big frustration at the time... =A0I'd somehow blocked it from > my memory when Juli and I talked about this a while ago... > > : The folks in the VM world suggested we change this to PTE_xxx which I > : did. > > Alan Cox, if memory serves. I had tested the changes (buildworld on 32 cpus) , so there is a chance that the problem no longer exists. There is one minor cleanup in the patch that can be done (ie unify the mips_pg and pmap_pte macros). But the renaming itself does not seem to buy us anything. I will wait for Juli's comments too, as she is the original author of the patch... JC. > Warner > > : R > : On Jun 17, 2010, at 11:38 AM, Jayachandran C. wrote: > : > : > On Tue, Jun 15, 2010 at 7:06 PM, Jayachandran C. > : > <c.jayachandran@gmail.com> wrote: > : >> I have volunteered to merge Juli's 64-bit work into HEAD, =A0and > : >> hopefully get it to work on XLR too. The tree > : >> (http://svn.freebsd.org/base/user/jmallett/octeon) has quite a bit o= f > : >> changes, so I would like to do this over multiple changesets and > : >> without breaking the current o32 code. > : > > : > Here's part 2, containing two patches: > : > > : > pmap-PTE-to-PG.patch : > : > > : > This is a renaming patch with minor cleanup, The PTE_* flags are > : > renamed to PG_ and related changes are made to other files. I have > : > tried to make this patch limited to just the renaming and the changes > : > related to it. =A0I will make another patch for the rest of the minor > : > changes in pmap.c. > : > > : > My comment on this patch: The name PG_C_CNC for value 3 in pte.h may > : > be confusing, at least on XLR. We don't have cached non-coherent mode= , > : > the cached memory is coherent(except L1 I-cache), so I would prefer > : > PG_CACHED and PG_UNCACHED names. > : > > : > pmap-lgmem-lock-remove.patch : > : > > : > Remove the lock in local_sysmaps, and sched_pin()/unpin() in the > : > PMAP_LMEM_ macros. > : > > : > The 64-bit support changes would be next - comments on the patches > : > esp. the first one is welcome. > : > > : > Thanks, > : > JC. > : > <pmap-PTE-to-PG.patch><pmap-lgmem-lock-remove.patch> > : > : ------------------------------ > : Randall Stewart > : 803-317-4952 (cell) > : > : > --=20 C. Jayachandran c.jayachandran@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimkF47RlysFOrma0YhWNDw2w5Lcp9SB1bBoPuxW>