public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stephen C. Tweedie" <sct@redhat.com>
To: michaelc <michaelc@turbolinux.com.cn>
Cc: linux-kernel@vger.kernel.org, Stephen Tweedie <sct@redhat.com>
Subject: Re: about kmap_high function
Date: Tue, 3 Jul 2001 10:38:09 +0100	[thread overview]
Message-ID: <20010703103809.A29868@redhat.com> (raw)
In-Reply-To: <3620762046.20010629150601@turbolinux.com.cn>
In-Reply-To: <3620762046.20010629150601@turbolinux.com.cn>; from michaelc@turbolinux.com.cn on Fri, Jun 29, 2001 at 03:06:01PM +0800

Hi,

On Fri, Jun 29, 2001 at 03:06:01PM +0800, michaelc wrote:
>     I found that the kmap_high function didn't call __flush_tlb_one()
> when it mapped a highmem page sucessfully, and I think it maybe
> cause the problem that TLB may store obslete page table entries, but
> the kmap_atomic() function do call the __flush_tlb_one(), someone tell
> me what's the differenc between the kmap_atomic and kmap_high except
> that kmap_atomic can be used in IRQ contexts. I appreciate in advance.

kmap_high is intended to be called routinely for access to highmem
pages.  It is coded to be as fast as possible as a result.  TLB
flushes are expensive, especially on SMP, so kmap_high tries hard to
avoid unnecessary flushes.

The way it does it is to do only a single, complete TLB flush of the
whole kmap VA range once every time the kmap address ring cycles.
That's what flush_all_zero_pkmaps() does --- it evicts old, unused
kmap mappings and flushes the whole TLB range, so that we are
guaranteed that there is a TLB flush between any two different uses of
any given kmap virtual address.

That way, we can avoid the cost of having to flush the TLB for every
single kmap mapping we create.

Cheers,
 Stephen

  reply	other threads:[~2001-07-03  9:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-29  7:06 about kmap_high function michaelc
2001-07-03  9:38 ` Stephen C. Tweedie [this message]
2001-07-03 12:47   ` Paul Mackerras
2001-07-03 15:34     ` Stephen C. Tweedie
2001-07-04 11:48       ` Paul Mackerras
2001-07-05  2:28   ` Re[2]: " michaelc
2001-07-05 10:41     ` Stephen C. Tweedie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010703103809.A29868@redhat.com \
    --to=sct@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michaelc@turbolinux.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox