linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-mm@kvack.org,
	Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] pae-2.4.3-A4
Date: Sun, 25 Mar 2001 10:07:44 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.31.0103251001090.8737-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.30.0103251643070.6469-200000@elte.hu>


On Sun, 25 Mar 2001, Ingo Molnar wrote:
>
> one nontrivial issue was that on PAE the pgd has to be installed with
> 'present' pgd entries, due to a CPU erratum. This means that the
> pgd_present() code in mm/memory.c, while correct theoretically, doesnt
> work with PAE. An equivalent solution is to use !pgd_none(), which also
> works with the PAE workaround.

Note that due to the very same erratum, we really should populate the PGD
from the very beginning. See the other thread about how we currently
fail to properly invalidate the TLB on other CPU's when we add a new PGD
entry, exactly because the other CPU's are caching the "nonexistent" PGD
entry that we just replaced.

So my suggestion for PAE is:

 - populate in gdb_alloc() (ie just do the three "alloc_page()" calls to
   allocate the PMD's immediately)

   NOTE: This makes the race go away, and will actually speed things up as
   we will pretty much in practice always populate the PGD _anyway_, the
   way the VM areas are laid out.

 - make "pgd_present()" always return 1.

   NOTE: This will speed up the page table walkers anyway. It will also
   avoid the problem above.

 - make "free_pmd()" a no-op.

All of the above will (a) simplify things (b) remove special cases and (c)
remove actual and existing bugs.

(In fact, the reason why the PGD populate missing TLB invalidate probably
never happens in practice is exactly the fact that the PGD is always
populated so fast that it's hard to make a test-case that shows this. But
it's still a bug - probably fairly easily triggered by a threaded program
that is statically linked (so that the code loads at 0x40000000 and
doesn't have the loader linked low - so the lowest PGD entry is not
allocated until later).

Does anybody see any problems with the above? It looks like the obvious
fix.

		Linus

--
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/

  parent reply	other threads:[~2001-03-25 18:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33.0103191802330.2076-100000@mikeg.weiden.de>
2001-03-20  1:56 ` 3rd version of R/W mmap_sem patch available Rik van Riel
2001-03-19 22:46   ` Linus Torvalds
2001-03-20  2:46   ` Linus Torvalds
2001-03-20  4:15     ` Marcelo Tosatti
2001-03-20  6:07       ` Linus Torvalds
2001-03-20  4:29         ` Marcelo Tosatti
2001-03-20  6:36           ` Linus Torvalds
2001-03-20  7:03             ` Linus Torvalds
2001-03-20  8:19               ` Eric W. Biederman
2001-03-20 15:11     ` Andrew Morton
2001-03-20 15:15       ` Jeff Garzik
2001-03-20 15:16       ` Jeff Garzik
2001-03-20 15:31         ` Andrew Morton
2001-03-21  1:59           ` Eric W. Biederman
2001-03-20 16:08       ` Linus Torvalds
2001-03-20 16:33         ` Andi Kleen
2001-03-20 17:13           ` Linus Torvalds
2001-03-20 19:33           ` Rik van Riel
2001-03-20 22:51             ` Andrew Morton
2001-03-22 10:24         ` Andrew Morton
2001-03-25 14:53     ` [patch] pae-2.4.3-A4 Ingo Molnar
2001-03-25 16:33       ` Russell King
2001-03-25 18:07       ` Linus Torvalds [this message]
2001-03-25 18:51         ` Ingo Molnar

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=Pine.LNX.4.31.0103251001090.8737-100000@penguin.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    /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