Date: Sun, 26 Oct 2003 15:54:46 -0600 From: Alan Cox <alc@cs.rice.edu> To: Don Lewis <truckman@FreeBSD.org> Cc: cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <20031026215446.GD20658@cs.rice.edu> In-Reply-To: <200310260745.h9Q7jVeF020616@gw.catspoiler.org> References: <20031026041909.GY20658@cs.rice.edu> <200310260745.h9Q7jVeF020616@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031026215446.GD20658>