cvs commit: src/sys/i386/i386 pmap.c

[Alan Cox]

On Sun, Oct 26, 2003 at 12:45:31AM -0700, Don Lewis wrote:
> 
> 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.

You could.  My thoughts are:

 - Preemption encourages you, the kernel developer, to distinguish
   between what is shared and what is thread private, as opposed
   to what is shared and what is CPU private.  The distinction
   between thread private and CPU private only matters when you're
   dealing with low-level state such as TLBs.

 - The switchin mechanism is very simple to implement and use.
   Setup and shutdown are two assignment statements.  The overhead
   on a context switch is a conditional branch.  I don't think
   what you propose has any less overhead.
    - I expect, however, that our scheduler(s) will someday support
      what you propose.

 - Most of the overhead in pmap_zero_page() stems from the use
   of a single, shared KVA.  A mapping using that KVA is thread
   private, hence the use of the switchin mechanism to avoid IPIs
   for TLB shootdown, but the KVA itself is shared, hence the use
   of a mutex to control access to it.

 - I would rather see us eliminate the mutex by developing a low-
   overhead scheme for allocating temporary KVA.  This scheme, like
   the switchin mechanism, has many possible uses throughout the
   kernel, both for thread private and shared mappings.  In fact,
   this scheme might itself be implemented using CPU private data
   for efficiency.  That's ok as far as I'm concerned because we've
   then encapsulated the aspects of managing CPU private stuff
   behind one general-purpose API, rather than having it pop up
   in pmap_zero_page(), SMP optimized pipes, etc.

Regards,
Alan