From: "Stephen C. Tweedie" <sct@redhat.com>
To: Jamie Lokier <lk@tantalophile.demon.co.uk>
Cc: Ben LaHaise <bcrl@redhat.com>,
torvalds@transmeta.com, linux-mm@kvack.org
Subject: Re: [PATCH/RFC] fix missing tlb flush on x86 smp+pae
Date: Fri, 16 Mar 2001 13:34:45 +0000 [thread overview]
Message-ID: <20010316133445.N30889@redhat.com> (raw)
In-Reply-To: <20010316141234.B1805@pcep-jamie.cern.ch>; from lk@tantalophile.demon.co.uk on Fri, Mar 16, 2001 at 02:12:34PM +0100
Hi,
On Fri, Mar 16, 2001 at 02:12:34PM +0100, Jamie Lokier wrote:
> Ben LaHaise wrote:
> > Below is a patch for 2.4 (it's against 2.4.2-ac20) that fixes a case where
> > pmd_alloc could install a new entry without causing a tlb flush on other
> > CPUs. This was fatal with PAE because the CPU caches the top level of the
> > page tables, which was showing up as an infinite stream of identical page
> > faults.
>
> Ew. Is this the only case where adding a new entry requires a tlb
> flush? It is quite an unusual requirement.
On Intel, yes. The PAE case is a special case: we lose one bit of
addressing for each level of page table because the pte width has
doubled, so the two-level page table is short of two bits of address
coverage in PAE mode. The CPU solves this by implementing a third
level page table, but it's just a tiny four-entry table, and because
it is so small the CPU just caches the whole pgd internally.
So, updating the pgd contents in this special case requires a tlb
flush because it's the only case where the CPU is caching the contents
of page tables other than the leaf pte entries.
Fortunately, the pgd being so tiny also implies that we hardly ever
need to add new entries: we can only ever do so three times per
process, and exec will almost always populate it fully before it is
finished as we load the binary into the first pmd, the libraries into
the second and the stack into the third (the fourth is the kernel
address space).
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2001-03-16 13:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-15 19:50 Ben LaHaise
2001-03-16 13:12 ` Jamie Lokier
2001-03-16 13:34 ` Stephen C. Tweedie [this message]
2001-03-16 17:10 ` Linus Torvalds
2001-03-16 17:29 ` 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=20010316133445.N30889@redhat.com \
--to=sct@redhat.com \
--cc=bcrl@redhat.com \
--cc=linux-mm@kvack.org \
--cc=lk@tantalophile.demon.co.uk \
--cc=torvalds@transmeta.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