Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Oct 2003 00:45:31 -0700 (PDT)
From:      Don Lewis <truckman@FreeBSD.org>
To:        alc@cs.rice.edu
Cc:        cvs-src@FreeBSD.org
Subject:   Re: cvs commit: src/sys/i386/i386 pmap.c
Message-ID:  <200310260745.h9Q7jVeF020616@gw.catspoiler.org>
In-Reply-To: <20031026041909.GY20658@cs.rice.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25 Oct, Alan Cox wrote:
> On Sat, Oct 25, 2003 at 11:14:48PM -0400, Jeff Roberson wrote:
>> 
>> Uhm, dumb question, why don't we just allocate one page of kva per
>> processor and avoid the mutex, the switchin/out, etc?  To save KVA? At 3
>> pages per processor and a max of 8 processors on intel, that's 192k.  We
>> can probably spare it.  I just saved that much with some UMA tuning.
>> 
> 
> The mutex and the switchin mechanism are addressing two distinct needs.
> 
> The mutex exists because there is a single KVA for some low-level pmap
> functions on i386.  (This could be changed, eliminating the need for
> the mutex.)
> 
> If, however, you eliminate the need for the mutex, you still require
> the switchin mechanism as a means of handling preemption,
> specifically, migration of the preempted thread between CPUs.  The
> alternative is to make pmap_zero_page() and the like critical
> sections.

Why not allow preemption, but just mark the thread as being ineligable
for migration while it is executing pmap_zero_page() and similar bits of
code?  The thread might have to wait longer to get the CPU again after
it was preempted, but so what.



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