Re: CVS commit: src/sys/arch

["Cherry G. Mathew" <cherry.g.mathew%gmail.com@localhost>]

On 24 February 2012 15:33, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
wrote:
> On Fri, Feb 24, 2012 at 03:00:03PM +0530, Cherry G. Mathew wrote:
>> On 22 February 2012 18:31, Manuel Bouyer <bouyer%antioche.eu.org@localhost> 
>> wrote:
>> > On Wed, Feb 22, 2012 at 06:05:21PM +0530, Cherry G. Mathew wrote:
>> >>
>> >> I meant we could make it work, (it would already for amd64/xen since
>> >> cpu_init_msrs() is called from cpu_hatch()) since xen has its own cpu.c
>> >
>> > i don't know if we can do the same for i386.
>>
>> It wasn't fun, but I managed to do it.
>>
>> btw, do you see a gdt page leaked between machdep.c:initgdt() and
>> gdt.c:gdt_init() ?
>
> I can't see initgdt(), did you remove it ?

No, it's right there:
http://nxr.netbsd.org/xref/src/sys/arch/i386/i386/machdep.c#1096

>
>>
>> > Also xpq_cpu() is time-critical; I guess a function pointer call is faster
>> > than a test.
>>
>> Well, as a bonus of the early %gs/%fs setup now, I'm thinking of
>> pruning the xpq_queue_update_xxx() in favour of pmap_set_xxx(). Also,
>> I'll revisiting the atomicity guarantees (eg: pmap_pte_cas() of these
>> functions, once we only start using them.
>
> AFAIK they're already all used by pmap ?
>

Mostly, but not everywere.

> What I want to look at is *why* they're used. In some case it's only
> to collect PG_M/PG_D bits, and Xen has another, maybe more efficient
> mechanism for that. This may allow us to batch more MMU updates.
>
> Also, I want to look using more multicalls. This may decrease the
> number of hypercalls significantly.
>

I wonder if there's a way to align that with pmap(9) assumptions.
Quoting the manpage:

"     In order to cope with hardware architectures that make the invalidation
     of virtual address mappings expensive (e.g., TLB invalidations, TLB
     shootdown operations for multiple processors), the pmap module is allowed
     to delay mapping invalidation or protection operations until such time as
     they are actually necessary.  The functions that are allowed to delay
     such actions are pmap_enter(), pmap_remove(), pmap_protect(),
     pmap_kenter_pa(), and pmap_kremove().  Callers of these functions must
     use the pmap_update() function to notify the pmap module that the map-
     pings need to be made correct.  Since the pmap module is provided with
     information as to which processors are using a given physical map, the
     pmap module may use whatever optimizations it has available to reduce the
     expense of virtual-to-physical mapping synchronization.
"
Since the XPQ can be regarded as a kind of TLB, I'm guessing we can
attempt to marry the two apis ?

Cheers,
-- 
~Cherry