From: Thiemo Seufer <ths@networkno.de>
To: Peter Watkins <treestem@gmail.com>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>,
Jonathan Day <imipak@yahoo.com>
Subject: Re: [PATCH 2] 64K page size
Date: Fri, 25 Aug 2006 16:21:21 +0100 [thread overview]
Message-ID: <20060825152121.GF2887@networkno.de> (raw)
In-Reply-To: <44EF0C61.7090008@gmail.com>
Peter Watkins wrote:
> Hello,
>
> Attached is the rest of the 64K page patch. It's been tested
> uniprocessor on Malta 20KC and 25KF. It also runs on a 6-way SMP
> functional simulator containing 5KF's. Ran tests with 16K and 64K page
> size.
>
> Question: Is there an SMP malta board?
You mean a SMP core card? None I heard of.
> There are 2 areas which could use improvement:
>
> (1) Because 64K is larger than a 15 bit immediate operand, I could not
> get the asm-offsets mechanism to produce the correct constants. So I
> enlisted a fairly gruesome hack of using #define's for _PAGE_SIZE and
> _THREAD_SIZE, for that page size. Hopefully someone has a better idea.
>
> (2) In tlbex.c:build_adjust_context(), I suspect the change for shift =
> PAGE_SHIFT - 12 should be more generally true, rather than just for the
> CPU's mentioned in the case statement.
It should be added to the initial shift calculation instead, i suspect
it will break 32bit kernels elsewise. It should be generally the same
for all CPUs with r4k-style TLBs.
> I was conservative there because
> I'm not familiar with the CPU_VR41* machines. Hopefully someone more
> intimate with that code can comment.
The vr41xx has a different/broken page mask in order to support 1k pages
(which aren't used by linux). The shift += 2 fixes this up.
[snip]
> index c06f63e..c9de17c 100644
> --- a/arch/mips/kernel/head.S
> +++ b/arch/mips/kernel/head.S
> @@ -190,7 +190,12 @@ #endif /* CONFIG_MIPS_MT_SMTC */
>
> MTC0 zero, CP0_CONTEXT # clear context register
> PTR_LA $28, init_thread_union
> +#ifdef CONFIG_PAGE_SIZE_64KB
> + PTR_ADDIU sp, $28, (_THREAD_SIZE - 32)/2
> + PTR_ADDIU sp, sp, (_THREAD_SIZE - 32)/2
> +#else
> PTR_ADDIU sp, $28, _THREAD_SIZE - 32
> +#endif
A PTR_LI ... ; PTR_ADDU sequence would be better, without an #ifdef.
This isn't a critical path of execution, and one day we might go for
even bigger pagesizes. Likewise for the other doubled addiu in this
patch.
[snip]
> diff --git a/arch/mips/mm/tlbex.c b/arch/mips/mm/tlbex.c
> index 375e099..bf093aa 100644
> --- a/arch/mips/mm/tlbex.c
> +++ b/arch/mips/mm/tlbex.c
> @@ -97,6 +97,8 @@ #define FUNC_SH 0
> #define SET_MASK 0x7
> #define SET_SH 0
>
> +#define OP_ERET 0x42000018
> +
> enum opcode {
> insn_invalid,
> insn_addu, insn_addiu, insn_and, insn_andi, insn_beq,
> @@ -631,6 +633,9 @@ static __init void copy_handler(struct r
> static __init int __attribute__((unused)) insn_has_bdelay(struct reloc *rel,
> u32 *addr)
> {
> + if (*addr == OP_ERET)
> + return 1;
> +
Why? Eret has no BD slot.
> for (; rel->lab != label_invalid; rel++) {
> if (rel->addr == addr
> && (rel->type == R_MIPS_PC16
> @@ -996,7 +1001,12 @@ #else
> #endif
>
> l_vmalloc_done(l, *p);
> - i_dsrl(p, tmp, tmp, PGDIR_SHIFT-3); /* get pgd offset in bytes */
> +
> + /* Want PGDIR_SHIFT-3 here, but break it into two ops so we don't
> + * exceed the max shift amount of 31 with large page sizes. */
> + i_dsrl(p, tmp, tmp, PGDIR_SHIFT-16); /* get pgd offset in bytes */
> + i_dsrl(p, tmp, tmp, 16-3); /* get pgd offset in bytes */
This cries for a single i_dsrl32 for the large page case.
> +
> i_andi(p, tmp, tmp, (PTRS_PER_PGD - 1)<<3);
> i_daddu(p, ptr, ptr, tmp); /* add in pgd offset */
> i_dmfc0(p, tmp, C0_BADVADDR); /* get faulting address */
> @@ -1087,6 +1097,11 @@ static __init void build_adjust_context(
> case CPU_VR4133:
> shift += 2;
> break;
> + case CPU_20KC:
> + case CPU_25KF:
> + case CPU_5KC:
> + shift = PAGE_SHIFT - 12;
> + break;
As said, should be done for all CPUs. (This will also fix the vr41xx
case, just in case somebody is crazy enough to go for large pages
on his PDA. :-)
Thiemo
next prev parent reply other threads:[~2006-08-25 15:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-25 14:42 [PATCH 2] 64K page size Peter Watkins
2006-08-25 15:04 ` Ralf Baechle
2006-08-25 15:21 ` Thiemo Seufer [this message]
2006-08-29 17:27 ` [PATCH 3] " Peter Watkins
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=20060825152121.GF2887@networkno.de \
--to=ths@networkno.de \
--cc=imipak@yahoo.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=treestem@gmail.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