From: michaelc <michaelc@turbolinux.com.cn>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re[2]: about kmap_high function
Date: Thu, 5 Jul 2001 10:28:35 +0800 [thread overview]
Message-ID: <1224736781.20010705102835@turbolinux.com.cn> (raw)
In-Reply-To: <20010703103809.A29868@redhat.com>
In-Reply-To: <3620762046.20010629150601@turbolinux.com.cn> <20010703103809.A29868@redhat.com>
Hi,
Tuesday, July 03, 2001, 5:38:09 PM, you wrote:
SCT> kmap_high is intended to be called routinely for access to highmem
SCT> pages. It is coded to be as fast as possible as a result. TLB
SCT> flushes are expensive, especially on SMP, so kmap_high tries hard to
SCT> avoid unnecessary flushes.
SCT> The way it does it is to do only a single, complete TLB flush of the
SCT> whole kmap VA range once every time the kmap address ring cycles.
SCT> That's what flush_all_zero_pkmaps() does --- it evicts old, unused
SCT> kmap mappings and flushes the whole TLB range, so that we are
SCT> guaranteed that there is a TLB flush between any two different uses of
SCT> any given kmap virtual address.
SCT> That way, we can avoid the cost of having to flush the TLB for every
SCT> single kmap mapping we create.
Thank you very much for your kindly guide, and I have two question to ask
you, One question is, Is kmap_high intended to be called merely in the user
context, so the highmem pages are mapped into user process page table, so
on SMP, other processes ( including kernel and user process) that running
on another cpu doesn't need to get that kmap virtual address.
Another question is, when kernel evicts old, unused kmap mapping and
flushes the whole TLB range( call the flush_all_zero_pkmaps), the TLB won't
keep those zero mappings, after that, when user process call kmap_high to
get a new kmap mappings, and when the process access that virtual
address, MMU component will get the page directory and page table from MEMORY
instead of TLB to translate the virtual address into physical address.
--
Best regards,
Michael Chen mailto:michaelc@turbolinux.com.cn
next prev parent reply other threads:[~2001-07-05 2:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-29 7:06 michaelc
2001-07-03 9:38 ` Stephen C. Tweedie
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 ` michaelc [this message]
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=1224736781.20010705102835@turbolinux.com.cn \
--to=michaelc@turbolinux.com.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/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
all inboxes | Powered by JetHome®