On Wed, 2007-10-03 at 13:13 +1000, Paul Mackerras wrote:
> Will Schmidt writes:
>
> > I still need to test this code for performance issues, and this version
> > could still use some cosmetic touchups, so I dont think we want this to
> > go into a tree yet. I am reposting this primarily to indica
On Wed, Oct 03, 2007 at 01:07:58PM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > > This makes the kernel use 1TB segments for all kernel mappings and for
> > > user addresses of 1TB and above, on machines which support them
> > > (currently POWER5+ and POWER6).
> >
> > PA6T supports
Will Schmidt writes:
> I still need to test this code for performance issues, and this version
> could still use some cosmetic touchups, so I dont think we want this to
> go into a tree yet. I am reposting this primarily to indicate the prior
> version isnt quite right, and so Jon can rebase to t
Olof Johansson writes:
> > This makes the kernel use 1TB segments for all kernel mappings and for
> > user addresses of 1TB and above, on machines which support them
> > (currently POWER5+ and POWER6).
>
> PA6T supports them as well :)
In the patch, we don't actually hard-code the CPU_FTR_1T_SEG
Hi,
On Tue, Oct 02, 2007 at 01:37:54PM -0500, Will Schmidt wrote:
> [RFC v2] 1TB Segment size support
>
> From: <>
>
> 1TB Segment size support
>
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (curren
> +static int __init htab_dt_scan_seg_sizes(unsigned long node,
> + const char *uname, int depth,
> + void *data)
> +{
> + char *type = of_get_flat_dt_prop(node, "device_type", NULL);
> + u32 *prop;
> + unsigned l
Paul Mackerras wrote:
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
>
A couple of hunks fail in this file when applying to the current tree.
...
> diff --git a/include/asm-powerpc/mmu-hash64.h
> b/include/asm-powerpc/mmu-hash64.h
> index 695962f..053f86b 100644
> --- a/include/a
On Thu, Aug 02, 2007 at 03:41:23PM -0500, Will Schmidt wrote:
> Hi Paul,
>just a few questions.
[snip]
> > +#define VSID_MULTIPLIER_256M ASM_CONST(200730139)/* 28-bit prime
> > */
>
> > +#define VSID_MULTIPLIER_1T ASM_CONST(12538073) /* 24-bit prime */
>
> Anything special i
On Fri, 2007-08-03 at 08:37 +1000, Benjamin Herrenschmidt wrote:
> > Is there technical reason why the 'local' variable remains at the end of
> > the parm list for these? In other cases 'ssize' simply gets added to
> > the end of the parm list.
>
> Looks nicer to have psize and ssize together :
> Is there technical reason why the 'local' variable remains at the end of
> the parm list for these? In other cases 'ssize' simply gets added to
> the end of the parm list.
Looks nicer to have psize and ssize together :-)
Ben.
___
Linuxppc-dev ma
Hi Paul,
just a few questions.
On Wed, 2007-08-01 at 12:04 +1000, Paul Mackerras wrote:
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6). We don't currently use 1TB seg
11 matches
Mail list logo
