Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Jul 2002 15:26:52 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Alan Cox <alc@cs.rice.edu>
Cc:        Peter Wemm <peter@wemm.org>, Jake Burkholder <jake@locore.ca>, Alan Cox <alc@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/vm vm_zeroidle.c
Message-ID:  <200207072226.g67MQqoT017816@apollo.backplane.com>
References:  <20020707211530.GZ11391@cs.rice.edu> <20020707212707.BD3713808@overcee.wemm.org> <20020707213541.GA11391@cs.rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help

:> Thats what I did to avoid reentrancy problems.  The zeroidle process uses
:> CMAP3 on x86.  (ugh! why not allocate some kvm? hmmm).
:> 
:> However, with preemption, we can end up on another cpu.  Or, we get
:> scheduled on a different cpu next time.  If we had a way to pin a khread to
:> a particular cpu, now that would be nice.  We could get in, pin ourselves,
:> do our mappings, zero the page, unmap, unpin and done.  No preemption
:> problems to worry about then, and no need to worry about coherency on other
:> cpus since this is explicitly single threaded.
:
:Let me suggest another way to deal with preemption: associate a flag
:with the pmap that says flush the TLB on activation even if you
:appear to be switching to the same page table, in this case the kernel's
:page table.  pmap_zero_page() would set and unset this flag around
:the bzero().
:
:Alan

    You mean CMAP2, not CMAP3, I think.

...
        *CMAP2 = PG_V | PG_RW | phys | PG_A | PG_M;
        invltlb_1pg((vm_offset_t)CADDR2);

#if defined(I686_CPU)
        if (cpu_class == CPUCLASS_686)
                i686_pagezero(CADDR2);
        else
#endif
                bzero(CADDR2, PAGE_SIZE);
        *CMAP2 = 0;
...

    Hmm.  pmap_copy_page() also uses CMAP2, wouldn't they collide with
    each other?  pmap_copy_page() and pmap_zero_page()?  Am I missing
    something here or does it work simply because all of this stuff is
    still under Giant?

    In anycase, an obvious but unpopular answer would be to use a 
    critical section.  One page == 4K @ 200 MBytes/sec = 20 uS latency.
    That would work as a temporary solution.  Or you could break the 
    zeroing operation down into four 1K segments within the critical
    section, invltlb'ing the page between each section giving you four
    5 uS critical sections.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207072226.g67MQqoT017816>