Merging 64 bit changes to -HEAD - part 2

[M. Warner Losh]

In message: <4B66E1A4-E2A5-471F-9FA4-38B506797272 at lakerest.net>
            Randall Stewart <rrs at lakerest.net> writes:
: 
: On Jun 17, 2010, at 12:23 PM, Jayachandran C. wrote:
: 
: > On Thu, Jun 17, 2010 at 9:32 PM, M. Warner Losh <imp at bsdimp.com>
: > wrote:
: >> In message: <98F8CB29-62FE-41A6-8AE6-6F8AF086D29C at lakerest.net>
: >>            Randall Stewart <rrs at 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...  I'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...
: >
: 
: But JC:
: 
: I don't understand why you have this urge to move PTE_xxx -> PG_xxx
: 
: a) We had that and changed that
: b) Alan (I think you are right here Warner it was Alan that made the
: suggestion) suggested
:    the changes to PTE_xx
: 
: 
: So what are your reasons for wanting to do this?

It was also a name-space collision, so we were using PG_x instead of
PG_y in the PTE code due to the overlap.  Maybe it all works now, but
that was the motivation for the change.

Warner

: R
: 
: 
: > 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 at gmail.com> wrote:
: >> : >> I have volunteered to merge Juli's 64-bit work into HEAD,  and
: >> : >> hopefully get it to work on XLR too. The tree
: >> : >> (http://svn.freebsd.org/base/user/jmallett/octeon) has quite a
: >> bit of
: >> : >> 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.  I 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)
: >> :
: >> :
: >>
: >
: >
: >
: > -- 
: > C. Jayachandran    c.jayachandran at gmail.com
: >
: 
: ------------------------------
: Randall Stewart
: 803-317-4952 (cell)
: 
: