Merging 64 bit changes to -HEAD - part 2

[Jayachandran C.]

On Sat, Jun 19, 2010 at 9:49 PM, Alan Cox <alc at cs.rice.edu> wrote:
> On 6/19/2010 5:18 AM, Juli Mallett wrote:
>>
>> On Fri, Jun 18, 2010 at 12:41, Neel Natu<neelnatu at gmail.com>  wrote:
>>
>>>
>>> Hi JC,
>>>
>>> But what you really want here is to eliminate the intr_disable() and
>>> intr_restore() and keep sched_pin() and  sched_unpin().
>>>
>>
>> Are you sure?  I'm not.  By disabling interrupts we only have to
>> ensure that the fault path on any address we might access within those
>> routines doesn't need to use the large memory map.  This isn't
>> trivial, but I think we can acquire a reasonable confidence about it.
>> If we merely pin, we have to ensure that nothing else that can run
>> (including interrupts and threads that run via preemption) that would
>> access the large memory map — given that this includes routines like
>> pmap_zero_page, I think there's good reason for caution.  Disabling
>> interrupts is more conservative, but I think rightly-so.  I may be
>> mistaken.
>>
>
> You're not mistaken.  See, for example, the i386 pmap_zero_page().  Pinning
> by itself is insufficient because a pinned thread can be preempted, and the
> thread that then runs (on the same processor) could call pmap_zero_page().
>  So, pinning must be combined with a per-processor mutex.
>
> I can imagine that blocking interrupts on mips is cheaper than the
> combination of pinning and a mutex.  However, do you want to have interrupts
> blocked for the time it takes to read 4KB from DRAM and write 4KB to DRAM
> for pmap_copy_page()?  Ultimately, that's the question that you need to
> answer.

The original implementation was to lock and sched_pin(). As Neel
noted, the intr_disable was added later as a temporary fix.

I think we can go back to lock and pin. If there are no objections, I
will post a patch for this.

Thanks,
JC.