Re: CVS commit: src/sys/arch

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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 ?

> 
> > 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 ?

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.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--