All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Dan Malek <dan@embeddededge.com>,
	linux-ppc-embedded <linuxppc-embedded@ozlabs.org>
Subject: map_page() and pinned TLB entries
Date: Thu, 16 Jun 2005 11:47:39 -0300	[thread overview]
Message-ID: <20050616144739.GA1559@logos.cnet> (raw)

Hi Dan,

So we've got rid of direct pte manipulators similar to what was done in v2.4.

Such patch for v2.6 is in the 8xx tree I posted previously, you've also seen 
it here in the list. 

Remaining problem is that map_page() is going to flush the TLB for the 
addresses being created. Obviously there is a collision with the 4kb 
PTE's, which thrases the 8Mbyte entry.

So what I have done internally is to simply comment out the 
flush_HPTE() call in map_page(), which does the trick.

What would be an elegant way of dealing with this? We can insert
a conditional there such that only addresses not covered 
by other mappings (in this case the 8Mbyte entry) get flushed.

Any better ideas?


diff -Nur --exclude-from=/home/marcelo/excl /mnt/test2/tslinux_mv21/linux-2.6/arch/ppc/mm/pgtable.c linux-2.6/arch/ppc/mm/pgtable.c
--- /mnt/test2/tslinux_mv21/linux-2.6/arch/ppc/mm/pgtable.c     2005-05-16 13:19:47.000000000 -0300
+++ linux-2.6/arch/ppc/mm/pgtable.c     2005-06-16 15:52:32.000000000 -0300
@@ -299,8 +299,8 @@
        if (pg != 0) {
                err = 0;
                set_pte(pg, pfn_pte(pa >> PAGE_SHIFT, __pgprot(flags)));
-               if (mem_init_done)
-                       flush_HPTE(0, va, pmd_val(*pd));
+       //      if (mem_init_done)
+//                     flush_HPTE(0, va, pmd_val(*pd));
        }
        spin_unlock(&init_mm.page_table_lock);
        return err;

             reply	other threads:[~2005-06-16 19:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-16 14:47 Marcelo Tosatti [this message]
2005-06-16 21:13 ` map_page() and pinned TLB entries Dan Malek
2005-06-16 16:47   ` Marcelo Tosatti
2005-06-16 22:17     ` Dan Malek

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=20050616144739.GA1559@logos.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.