On Fri, Feb 24, 2012 at 03:00:03PM +0530, Cherry G. Mathew wrote:
> On 22 February 2012 18:31, Manuel Bouyer <bou...@antioche.eu.org> 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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
