From: "Stephen C. Tweedie" <sct@redhat.com>
To: michaelc <michaelc@turbolinux.com.cn>
Cc: "Stephen C. Tweedie" <sct@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: about kmap_high function
Date: Thu, 5 Jul 2001 11:41:21 +0100 [thread overview]
Message-ID: <20010705114121.J28793@redhat.com> (raw)
In-Reply-To: <3620762046.20010629150601@turbolinux.com.cn> <20010703103809.A29868@redhat.com> <1224736781.20010705102835@turbolinux.com.cn>
In-Reply-To: <1224736781.20010705102835@turbolinux.com.cn>; from michaelc@turbolinux.com.cn on Thu, Jul 05, 2001 at 10:28:35AM +0800
Hi,
On Thu, Jul 05, 2001 at 10:28:35AM +0800, michaelc wrote:
> 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.
No. In user context, at least for user data pages, the highmem pages
can be mapped into the local process's user page tables and we don't
need kmap to access them at all. kmap is only needed for pages which
are not already in the user page tables, such as when accessing the
page cache in read or write syscalls.
> 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.
No, user processes never access kmap addresses. They have direct page
table access to highmem pages in their address space. Only the kernel
uses kmap, and only for pages which are not in the calling process's
local page tables already. So we don't have to worry about keeping
kmap and page tables consistent --- they are totally different address
spaces, and the kmap virtual addresses are not visible to user
processes.
Cheers,
Stephen
prev parent reply other threads:[~2001-07-05 10:42 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
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 [this message]
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=20010705114121.J28793@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