From: Pantelis Antoniou <panto@intracom.gr>
To: Tom Rini <trini@kernel.crashing.org>
Cc: Dan Malek <dan@embeddededge.com>,
Kumar Gala <kumar.gala@motorola.com>,
Linuxppc-Embedded <linuxppc-embedded@lists.linuxppc.org>,
Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH #4/9] 8xx-2.6 | MM tweaks
Date: Fri, 28 May 2004 09:48:06 +0300 [thread overview]
Message-ID: <40B6E0A6.2060005@intracom.gr> (raw)
In-Reply-To: <20040527165316.GF6763@smtp.west.cox.net>
Tom Rini wrote:
>On Wed, May 26, 2004 at 03:05:45PM +0300, Pantelis Antoniou wrote:
>
>
>>Hi
>>
>>The following patch consists of minor tweaks in order to get
>>the mm to work.
>>
>
>I was wondering. The fault.c change boils down to:
>===== arch/ppc/mm/fault.c 1.26 vs edited =====
>--- 1.26/arch/ppc/mm/fault.c 2004-05-25 04:50:34 -07:00
>+++ edited/arch/ppc/mm/fault.c 2004-05-27 09:48:17 -07:00
>@@ -350,11 +350,14 @@
> pgd_t *dir;
> pmd_t *pmd;
> pte_t *pte;
>+ struct mm_struct *mm;
>
> if (address < TASK_SIZE)
>- return NULL;
>+ mm = current->mm;
>+ else
>+ mm = &init_mm;
>
>- dir = pgd_offset(&init_mm, address);
>+ dir = pgd_offset(mm, address & PAGE_MASK);
> if (dir) {
> pmd = pmd_offset(dir, address & PAGE_MASK);
> if (pmd && pmd_present(*pmd)) {
>
>Can you explain this a bit more? Looking back at the history in
>BitKeeper, this change came from Paul, in the changeset with the
>comments of:
>PPC update for the recent changes to the pgd/pmd/pte functions.
>This implements ptes-in-highmem for PPC, removes the quicklist
>and zero-page stuff. PTEs in highmem on SMP turned out to need
>some significant changes to avoid deadlocks on the hash_table_lock
>(now renamed to mmu_hash_lock). The PMDs now contain the physical
>address of the PTE page rather than the virtual address.
>Anything that takes the mmu_hash_lock now operates with the DMMU
>off to avoid MMU hash-table misses.
>
>And for this file in particular:
>Do pte_unmap after get_pteptr; use pte_offset_kernel instead of
>pte_offset in a couple of places.
>
>Which you exactly reverted. Were the changes from Paul incorrect here?
>Or is perhaps there something more needed on the 8xx side of things?
>
>
Let me tell you, I didn't know any of this stuff :).
My algorithm for the changes was simple.
1. Assume that linuxppc_2.4 is more recent that linuxppc-2.5 on 8xx.
2. Forward port any significant changes to 2.5.
3. Test.
If this didn't work, then I would try to fix anything more
complicated.
Thankfully it wasn't neccesary.
Regards
Pantelis
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2004-05-28 6:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-26 12:05 [PATCH #4/9] 8xx-2.6 | MM tweaks Pantelis Antoniou
2004-05-27 16:53 ` Tom Rini
2004-05-28 6:48 ` Pantelis Antoniou [this message]
2004-05-28 7:21 ` Dan Malek
2004-05-29 0:09 ` Paul Mackerras
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=40B6E0A6.2060005@intracom.gr \
--to=panto@intracom.gr \
--cc=dan@embeddededge.com \
--cc=kumar.gala@motorola.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=paulus@samba.org \
--cc=trini@kernel.crashing.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).