Merging 64 bit changes to -HEAD - part 2

Neel Natu neelnatu at gmail.com
Fri Jun 18 19:41:41 UTC 2010


Hi JC,

On Thu, Jun 17, 2010 at 10:59 PM, Jayachandran C.
<c.jayachandran at gmail.com> wrote:
> On Fri, Jun 18, 2010 at 4:00 AM, Randall Stewart <rrs at lakerest.net> wrote:
>>
>> On Jun 17, 2010, at 1:05 PM, M. Warner Losh wrote:
>>>
>>> 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.
>>
>>
>>
>> Yes, basically if I remember right someone used
>>
>> PG_GLOBAL instead of PG_G. This caused the wrong bits
>> to be set.
>>
>> In general I think its a BAD idea to have two name spaces in the
>> same section of the system (VM) that have similar define's that mean
>> different things.
>>
>>
>> Far better to KEEP the PTE_xxx or for that matter pick something else.. Just
>> NOT PG_xxx
>
> I was not aware of the PG/PTE history, I thought I would get the diffs
> against Juli's tree down.
>
> I will drop the renaming patch.
>
> But can you review/approve the second patch.  This change removes the
> sched_pin and lock in the LMEM macros.My understanding is that, these
> are not needed because each cpu is given its own va to map the
> physical memory to, and this pa/va mapping in in the kernel_pmap.
>

Your second patch as it stands looks good.

But what you really want here is to eliminate the intr_disable() and
intr_restore() and keep sched_pin() and  sched_unpin().

The interrupt disable hack was necessary when we would directly update
the TLB with the temporary mappings as opposed to going through the
kernel_pmap as we do now.  By instantiating the temporary mappings in
the kernel pmap we can rely on the TLB miss handler to put these
mappings in the TLB in case they get removed because of interrupt
processing.

See this change that introduced the interrupt disable code:
http://svn.freebsd.org/viewvc/base?view=revision&revision=203151

best
Neel

> JC.
> _______________________________________________
> freebsd-mips at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
> To unsubscribe, send any mail to "freebsd-mips-unsubscribe at freebsd.org"
>


More information about the freebsd-mips mailing list