* Re: [PATCH] [1/2] POWERPC: IOMMU support for honoring dma_mask
From: Olof Johansson @ 2006-04-14 18:55 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, plush, linux-kernel
In-Reply-To: <20060413020559.GC24769@pb15.lixom.net>
On Wed, Apr 12, 2006 at 09:05:59PM -0500, Olof Johansson wrote:
> Since time is somewhat of essense (if 2.6.17 is still an option), I went
> for the choice of sending now and follow up with a small bugfix later
> in case something shows up, especially since quick regression tests seem
> ok.
FYI, I now have a positive test report from a bcm43xx user with a 1.5GB G5.
(Thanks for testing this, Marc!).
-Olof
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Paul Mackerras @ 2006-04-14 19:07 UTC (permalink / raw)
To: Becky Bruce; +Cc: Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <21F7D7D8-B9BC-44EB-B07B-F888D89DCF25@freescale.com>
Becky Bruce writes:
> Actually, I think the problem is that the code linux is using to turn
> on nap mode is not guaranteed to put the processor in nap mode by the
> time the blr in ppc6xx_idle occurs.
Thanks, Becky.
This patch fixes it for me. Comments, anyone?
Paul.
diff -urN powerpc-merge/arch/powerpc/kernel/idle_6xx.S pmac-2.6.17-rc1/arch/powerpc/kernel/idle_6xx.S
--- powerpc-merge/arch/powerpc/kernel/idle_6xx.S 2006-04-04 23:09:16.000000000 -0700
+++ pmac-2.6.17-rc1/arch/powerpc/kernel/idle_6xx.S 2006-04-14 10:29:54.000000000 -0700
@@ -151,41 +151,47 @@
isync
mtmsr r7
isync
- sync
- blr
+1: b 1b
/*
* Return from NAP/DOZE mode, restore some CPU specific registers,
* we are called with DR/IR still off and r2 containing physical
- * address of current.
+ * address of current. R11 and CR contain HID0. We have to preserve
+ * r10 and r12.
*/
_GLOBAL(power_save_6xx_restore)
+ tophys(r11, r1) /* Make the idle task do a blr */
+ lwz r9,_LINK(r11)
+ stw r9,_NIP(r11)
mfspr r11,SPRN_HID0
- rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1 EQ */
- cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
+ rlwinm r11,r11,0,10,8 /* Clear NAP */
BEGIN_FTR_SECTION
rlwinm r11,r11,0,9,7 /* Clear DOZE */
END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
mtspr SPRN_HID0, r11
#ifdef DEBUG
- beq cr1,1f
+ bf 9,1f
lis r11,(nap_return_count-KERNELBASE)@ha
lwz r9,nap_return_count@l(r11)
addi r9,r9,1
stw r9,nap_return_count@l(r11)
1:
#endif
-
+
+#ifdef CONFIG_SMP
rlwinm r9,r1,0,0,18
tophys(r9,r9)
lwz r11,TI_CPU(r9)
slwi r11,r11,2
+#else
+ li r11,0
+#endif
/* Todo make sure all these are in the same page
- * and load r22 (@ha part + CPU offset) only once
+ * and load r11 (@ha part + CPU offset) only once
*/
BEGIN_FTR_SECTION
- beq cr1,1f
+ bf 9,1f
addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha
lwz r9,nap_save_msscr0@l(r9)
mtspr SPRN_MSSCR0, r9
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-14 19:54 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17471.62187.774127.783000@cargo.ozlabs.ibm.com>
Hi,
On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
> Becky Bruce writes:
>
> > Actually, I think the problem is that the code linux is using to turn
> > on nap mode is not guaranteed to put the processor in nap mode by the
> > time the blr in ppc6xx_idle occurs.
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
The bf mnemonics had me scratching my head a while, it's not listed as
a simplified mnemonic in the 64-bit PEM. Two questions below.
> _GLOBAL(power_save_6xx_restore)
> + tophys(r11, r1) /* Make the idle task do a blr */
> + lwz r9,_LINK(r11)
> + stw r9,_NIP(r11)
> mfspr r11,SPRN_HID0
> - rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1 EQ */
> - cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
> + rlwinm r11,r11,0,10,8 /* Clear NAP */
> BEGIN_FTR_SECTION
> rlwinm r11,r11,0,9,7 /* Clear DOZE */
> END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
> mtspr SPRN_HID0, r11
>
> #ifdef DEBUG
> - beq cr1,1f
> + bf 9,1f
Where is cr0 set now -- you took the dot off of rlwinm?
> lis r11,(nap_return_count-KERNELBASE)@ha
> lwz r9,nap_return_count@l(r11)
> addi r9,r9,1
> stw r9,nap_return_count@l(r11)
> 1:
> #endif
> -
> +
> +#ifdef CONFIG_SMP
> rlwinm r9,r1,0,0,18
> tophys(r9,r9)
> lwz r11,TI_CPU(r9)
> slwi r11,r11,2
> +#else
> + li r11,0
> +#endif
> /* Todo make sure all these are in the same page
> - * and load r22 (@ha part + CPU offset) only once
> + * and load r11 (@ha part + CPU offset) only once
> */
> BEGIN_FTR_SECTION
> - beq cr1,1f
> + bf 9,1f
Same comment as above w.r.t. cr0?
-Olof
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-14 20:00 UTC (permalink / raw)
To: Olof Johansson
Cc: linuxppc-dev list, Michael Schmitz, debian-powerpc,
Paul Mackerras
In-Reply-To: <20060414195436.GC24769@pb15.lixom.net>
He's being sneaky - there's a copy of HID0 in the CR at this point
from the caller, and bit 9 is the position for NAP.
-B
On Apr 14, 2006, at 2:54 PM, Olof Johansson wrote:
> Hi,
>
> On Fri, Apr 14, 2006 at 12:07:23PM -0700, Paul Mackerras wrote:
>> Becky Bruce writes:
>>
>>> Actually, I think the problem is that the code linux is using to
>>> turn
>>> on nap mode is not guaranteed to put the processor in nap mode by
>>> the
>>> time the blr in ppc6xx_idle occurs.
>>
>> Thanks, Becky.
>>
>> This patch fixes it for me. Comments, anyone?
>
> The bf mnemonics had me scratching my head a while, it's not listed as
> a simplified mnemonic in the 64-bit PEM. Two questions below.
>
>> _GLOBAL(power_save_6xx_restore)
>> + tophys(r11, r1) /* Make the idle task do a blr */
>> + lwz r9,_LINK(r11)
>> + stw r9,_NIP(r11)
>> mfspr r11,SPRN_HID0
>> - rlwinm. r11,r11,0,10,8 /* Clear NAP & copy NAP bit !state to cr1
>> EQ */
>> - cror 4*cr1+eq,4*cr0+eq,4*cr0+eq
>> + rlwinm r11,r11,0,10,8 /* Clear NAP */
>> BEGIN_FTR_SECTION
>> rlwinm r11,r11,0,9,7 /* Clear DOZE */
>> END_FTR_SECTION_IFSET(CPU_FTR_CAN_DOZE)
>> mtspr SPRN_HID0, r11
>>
>> #ifdef DEBUG
>> - beq cr1,1f
>> + bf 9,1f
>
> Where is cr0 set now -- you took the dot off of rlwinm?
>
>> lis r11,(nap_return_count-KERNELBASE)@ha
>> lwz r9,nap_return_count@l(r11)
>> addi r9,r9,1
>> stw r9,nap_return_count@l(r11)
>> 1:
>> #endif
>> -
>> +
>> +#ifdef CONFIG_SMP
>> rlwinm r9,r1,0,0,18
>> tophys(r9,r9)
>> lwz r11,TI_CPU(r9)
>> slwi r11,r11,2
>> +#else
>> + li r11,0
>> +#endif
>> /* Todo make sure all these are in the same page
>> - * and load r22 (@ha part + CPU offset) only once
>> + * and load r11 (@ha part + CPU offset) only once
>> */
>> BEGIN_FTR_SECTION
>> - beq cr1,1f
>> + bf 9,1f
>
> Same comment as above w.r.t. cr0?
>
>
>
> -Olof
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Paul Mackerras @ 2006-04-14 20:19 UTC (permalink / raw)
To: Olof Johansson
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <20060414195436.GC24769@pb15.lixom.net>
Olof Johansson writes:
> Where is cr0 set now -- you took the dot off of rlwinm?
transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
(doh!).
Paul.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Olof Johansson @ 2006-04-14 20:24 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17472.984.760483.334447@cargo.ozlabs.ibm.com>
On Fri, Apr 14, 2006 at 01:19:36PM -0700, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > Where is cr0 set now -- you took the dot off of rlwinm?
>
> transfer_to_handler does mfspr r11,SPRN_HID0; mtcr r11 before jumping
> to power_save_6xx_restore. The rlwinm. was wrong anyway since it was
> setting cr0.eq based on all the *other* bits in HID0, not HID0_NAP
> (doh!).
Oh, right, you even updated the comment to reflect this. My bad.
Patch looks good to me then.
-Olof
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Luck, Tony @ 2006-04-14 20:53 UTC (permalink / raw)
To: Mel Gorman; +Cc: davej, linuxppc-dev, ak, bob.picco, linux-kernel, linux-mm
In-Reply-To: <20060414131235.GA19064@skynet.ie>
On Fri, Apr 14, 2006 at 02:12:35PM +0100, Mel Gorman wrote:
> That appears fine, but I call add_active_range() after a GRANULEROUNDUP and
> GRANULEROUNDDOWN has taken place so that might be the problem, especially as
> all those ranges are aligned on a 16MiB boundary. The following patch calls
> add_active_range() before the rounding takes place. Can you try it out please?
That's good. Now I see identical output before/after your patch for
the generic (DISCONTIG=y) kernel:
On node 0 totalpages: 259873
DMA zone: 128931 pages, LIFO batch:7
Normal zone: 130942 pages, LIFO batch:7
-Tony
^ permalink raw reply
* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Benjamin Herrenschmidt @ 2006-04-14 20:57 UTC (permalink / raw)
To: Muli Ben-Yehuda; +Cc: Olof Johansson, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20060414144830.GQ10412@granada.merseine.nu>
> What I had in mind is an interface that given a PCI bridge will tell
> you what's the most restrictive DMA mask for a device on that bridge,
> so that you'll know whether you need to enable the IOMMU for that
> bridge. I'll even settle for a function that tells you what's the most
> restrictive DMA mask in the system, preiod. There's nothing inherently
> arch specific about this.
>
> (and as a side note, the IOMMU we are working on on x86-64 is Calgary,
> which is actually roughly the same chipset used in some PPC
> machines...)
Not sure I ever heard about that... What chipsets ?
Ben.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Benjamin Herrenschmidt @ 2006-04-14 21:01 UTC (permalink / raw)
To: Paul Mackerras
Cc: Becky Bruce, Michael Schmitz, debian-powerpc, linuxppc-dev list
In-Reply-To: <17471.62187.774127.783000@cargo.ozlabs.ibm.com>
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
> Becky Bruce writes:
>
> > Actually, I think the problem is that the code linux is using to turn
> > on nap mode is not guaranteed to put the processor in nap mode by the
> > time the blr in ppc6xx_idle occurs.
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
Looks good to me except that we need the same for ppc64 since the 970
theorically has the same problem...
Ben.
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Becky Bruce @ 2006-04-14 21:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, debian-powerpc
In-Reply-To: <20060414202452.GD24769@pb15.lixom.net>
On Fri, 2006-04-14 at 12:07 -0700, Paul Mackerras wrote:
> Becky Bruce writes:
>
>
>> Actually, I think the problem is that the code linux is using to turn
>> on nap mode is not guaranteed to put the processor in nap mode by the
>> time the blr in ppc6xx_idle occurs.
>>
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
Patch LGTM, as well. I like the approach.
Thanks!
-Becky
^ permalink raw reply
* [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-14 21:18 UTC (permalink / raw)
To: LKML, Andrew Morton
Cc: linux-mips, David Mosberger-Tang, linux-ia64, Martin Mares, spyro,
Joe Taylor, linuxppc-dev, paulus, benedict.gaster, bjornw,
Ingo Molnar, grundler, starvik, Linus Torvalds, Thomas Gleixner,
rth, chris, tony.luck, Andi Kleen, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
The current method of allocating space for per_cpu variables in modules
is not robust and consumes quite a bit of space.
per_cpu variables:
The per_cpu variables are declared by code that needs to have variables
spaced out by cache lines on SMP machines, such that, writing to any of
these variables on one CPU wont be in danger of writing into a cache
line of a global variable shared by other CPUs. If this were to happen,
the performance would go down by having the CPUs unnecessarily needing
to update cache lines across CPUs for even read only global variables.
To solve this, a developer needs only to declare a per_cpu variable
using the DECLARE_PER_CPU(type, var) macro. This would then place the
variable into the .data.percpu section. On boot up, an area is
allocated by the size of this section + PERCPU_ENOUGH_ROOM (mentioned
later) times NR_CPUS. Then the .data.percpu section is copied into this
area once for NR_CPUS. The .data.percpu section is later discarded (the
variables now exist in the allocated area).
The __per_cpu_offset[] array holds the difference between
the .data.percpu section and the location where the data is actually
stored. __per_cpu_offset[0] holds the difference for the variables
assigned to cpu 0, __per_cpu_offset[1] holds the difference for the
variables to cpu 1, and so on.
To access a per_cpu variable, the per_cpu(var, cpu) macro is used. This
macro returns the address of the variable (still pointing to the
discarded .data.percpu section) plus the __per_cpu_offset[cpu]. So the
result is the location to the actual variable for the specified CPU
located in the allocated area.
Modules:
Since there is no way to know from per_cpu if the variable was part of a
module, or part of the kernel, the variables for the module need to be
located in the same allocated area as the per_cpu variables created in
the kernel.
Why is that?
The per_cpu variables are used in the kernel basically like normal
variables. For example:
with:
DEFINE_PER_CPU(int, myint);
we can do the following:
per_cpu(myint, cpu) = 4;
int i = per_cpu(myint, cpu);
int *i = &per_cpu(myint, cpu);
Not to mention that we can export these variables as well so that a
module can be using a per_cpu variable from the kernel, or even declared
in another module and exported (the net code does this).
Now remember, the variables are still located in the discarded sections,
but their content is in allocated space offset per cpu. We have a
single array storing these offsets (__per_cpu_offset). So this makes it
very difficult to define special DEFINE/DECLARE_PER_CPU macros and use
the CONFIG_MODULE to play magic in figuring things out. Mainly because
we have one per_cpu macro that can be used in a module referencing
per_cpu variables declared in the kernel, declared in the given module,
or even declared in another module.
PERCPU_ENOUGH_ROOM:
When you configure an SMP kernel with loadable modules, the kernel needs
to take an aggressive stance and preallocate enough room to hold the
per_cpu variables in all the modules that could be loaded. To make
matters worst, this space is allocated per cpu! So if you have a 64
processor machine with loadable modules, you are allocating extra space
for each of the 64 CPUs even if you never load a module that has a
per_cpu variable in it!
Currently PERCPU_ENOUGH_ROOM is defined as 32768 (32K). On my 2x intel
SMP machine, with my normal configuration, using 2.6.17-rc1, the size
of .data.percpu is 17892 (17K). So the extra space for the modules is
32768 - 17892 = 14876 (14K). Now this is needed for every CPU so I am
actually using
14876 * 2 = 29752 (or 29K).
Now looking at the modules that I have loaded, none of them had
a .data.percpu section defined, so that 29K was a complete waste!
So the current solution has two flaws:
1. not robust. If we someday add more modules that together take up
more than 14K, we need to manually update the PERCPU_ENOUGH_ROOM.
2. waste of memory. We have 14K of memory wasted per CPU. Remember
a 64 processor machine would be wasting 896K of memory!
A solution:
I spent some time trying to come up with a solution to all this.
Something that wouldn't be too intrusive to the way things already work.
I received nice input from Andi Kleen and Thomas Gleixner. I first
tried to use the __builtin_choose_expr and __builtin_types_compatible_p
to determine if a variable is from the kernel or modules at compile
time. But unfortunately, I've been told that makes things too complex,
but even worst it had "show stopping" flaws.
Ideally this could be resolved at link time of the module, but that too
would require looking into the relocation tables which are different for
every architecture. This would be too intrusive, and prone to bugs.
So I went for a much simpler solution. This solution is not optimal in
saving space, but it does much better than what is currently
implemented, and is still easy to understand and manage, which alone may
outweigh an optimal space solution.
First off, if CONFIG_SMP or CONFIG_MODULES is not set, the solution is
the same as it currently is. So my solution only affects the kernel if
both CONFIG_SMP and CONFIG_MODULES are set (this is the same
configuration that wastes the memory in the current implementation).
I created a new section called, .data.percpu_offset. This section will
hold a pointer for every variable that is declared as per_cpu with
DEFINE_PER_CPU. Although this wastes space too, the amount of space
needed for my setup (the same configuration that wastes 14K per cpu) is
4368 (4K). Since this section is not copied for every CPU, this saves
us 10K for the first cpu (14 - 4) and 14K for every CPU after that! So
this saves on my setup 24K. (Note: I noticed that I used the default
NR_CPUS which is 8, so this really saved me 108K).
The data in .data.percpu_offset holds is referenced by the per_cpu
variable name which points to the __per_cpu_offset array. For modules,
it will point to the per_cpu_offset array of the module.
Example:
DEFINE_PER_CPU(int, myint);
would now create a variable called per_cpu_offset__myint in
the .data.percpu_offset section. This variable will point to the (if
defined in the kernel) __per_cpu_offset[] array. If this was a module
variable, it would point to the module per_cpu_offset[] array which is
created when the modules is loaded.
So now I get rid of the PERCPU_ENOUGH_ROOM constant and some of the
complexity in kernel/module.c that shares code with the kernel, and each
module has it's own allocation of per_cpu data. And this means the
per_cpu data is more robust (can handle future changes in the modules)
and saves up space.
Draw backs:
The one draw back I have on this, is because the DECLARE_PER_CPU macro
declares two variables now, you can't declare a "static DEFINE_PER_CPU".
So instead I created a DEFINE_STATIC_PER_CPU macro to handle this case.
The following patch set is against 2.6.17-rc1, but this patch set is
currently only for i386. I have a x86_64 that I can work on to port,
but I will need the help of others to port to some other archs, mostly
the other 64 bit archs. I tried to CC the maintainers of the other
archs (those listed in the vmlinux.lds, include/asm-<arch>/percpu.h
files and the MAINTAINER file).
I'm not going to spam the CC list (nor Andrew) with the rest of the
patches (only 5). Please see LKML for the rest.
-- Steve
^ permalink raw reply
* BDI-2000 Config file for MPC8349 eval board
From: Ben Warren @ 2006-04-14 22:03 UTC (permalink / raw)
To: Linuxppc-embedded
Hello,
Does anybody have a solid config file for the Freescale MPC8349EMDS eval
board? I guess the MPC8349ADS would be fine too, since I've been told
they're the same thing. I've been tweaking the file named
'mcp8349e.cfg' that shipped with the BDI, but it's a bit flaky with my
board. In particular, sometimes it can't write to the Flash programming
workspace, maybe indicating that the DDR isn't properly set up, but
there have been other things too that are slowly eating at me.
thanks,
Ben
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Andrew Morton @ 2006-04-14 22:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-mips, davidm, linux-ia64, mj, spyro, joe, ak, linuxppc-dev,
paulus, benedict.gaster, bjornw, mingo, grundler, starvik,
torvalds, tglx, rth, chris, tony.luck, linux-kernel, ralf, marc,
lethal, schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145049535.1336.128.camel@localhost.localdomain>
Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Example:
>
> DEFINE_PER_CPU(int, myint);
>
> would now create a variable called per_cpu_offset__myint in
> the .data.percpu_offset section.
Suppose two .c files each have
DEFINE_STATIC_PER_CPU(myint)
Do we end up with two per_cpu_offset__myint's in the same section?
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-14 22:12 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mips, davidm, linux-ia64, mj, spyro, joe, ak, linuxppc-dev,
paulus, benedict.gaster, bjornw, mingo, grundler, starvik,
torvalds, tglx, rth, chris, tony.luck, linux-kernel, ralf, marc,
lethal, schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <20060414150625.3ba369d2.akpm@osdl.org>
On Fri, 14 Apr 2006, Andrew Morton wrote:
> Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Example:
> >
> > DEFINE_PER_CPU(int, myint);
> >
> > would now create a variable called per_cpu_offset__myint in
> > the .data.percpu_offset section.
>
> Suppose two .c files each have
>
> DEFINE_STATIC_PER_CPU(myint)
>
> Do we end up with two per_cpu_offset__myint's in the same section?
>
Both variables are defined as static:
ie.
#define DEFINE_STATIC_PER_CPU(type, name) \
static __attribute__((__section__(".data.percpu_offset"))) unsigned long *per_cpu_offset__##name; \
static __attribute__((__section__(".data.percpu"))) __typeof__(type) per_cpu__##name
So the per_cpu_offset__myint is also static, and gcc should treat it
properly. Although, yes there are probably going to be two variables
named per_cpu_offset__myint in the same section, but the scope of those
should only be visible by who sees the static.
Works like any other variable that's static, and even the current way
DEFINE_PER_CPU works with statics.
Thanks,
-- Steve
^ permalink raw reply
* RE: [PATCH 00/05] robust per_cpu allocation for modules
From: Chen, Kenneth W @ 2006-04-14 22:12 UTC (permalink / raw)
To: 'Steven Rostedt', LKML, Andrew Morton
Cc: linux-mips, David Mosberger-Tang, linux-ia64, Martin Mares, spyro,
Joe Taylor, linuxppc-dev, paulus, benedict.gaster, bjornw,
Ingo Molnar, grundler, starvik, Linus Torvalds, Thomas Gleixner,
rth, chris, Luck, Tony, Andi Kleen, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145049535.1336.128.camel@localhost.localdomain>
Steven Rostedt wrote on Friday, April 14, 2006 2:19 PM
> So the current solution has two flaws:
> 1. not robust. If we someday add more modules that together take up
> more than 14K, we need to manually update the PERCPU_ENOUGH_ROOM.
> 2. waste of memory. We have 14K of memory wasted per CPU. Remember
> a 64 processor machine would be wasting 896K of memory!
If someone who has the money to own a 64-process machine, 896K of memory
is pocket change ;-)
- Ken
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Mel Gorman @ 2006-04-14 22:54 UTC (permalink / raw)
To: Luck, Tony
Cc: davej, linuxppc-dev, ak, bob.picco, Linux Kernel Mailing List,
Linux Memory Management List
In-Reply-To: <20060414205345.GA1258@agluck-lia64.sc.intel.com>
On Fri, 14 Apr 2006, Luck, Tony wrote:
> On Fri, Apr 14, 2006 at 02:12:35PM +0100, Mel Gorman wrote:
>> That appears fine, but I call add_active_range() after a GRANULEROUNDUP and
>> GRANULEROUNDDOWN has taken place so that might be the problem, especially as
>> all those ranges are aligned on a 16MiB boundary. The following patch calls
>> add_active_range() before the rounding takes place. Can you try it out please?
>
> That's good. Now I see identical output before/after your patch for
> the generic (DISCONTIG=y) kernel:
>
> On node 0 totalpages: 259873
> DMA zone: 128931 pages, LIFO batch:7
> Normal zone: 130942 pages, LIFO batch:7
>
Very very cool. Thanks for all the testing.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Benjamin Herrenschmidt @ 2006-04-14 22:57 UTC (permalink / raw)
To: Becky Bruce
Cc: Olof Johansson, linuxppc-dev list, Michael Schmitz,
debian-powerpc, Paul Mackerras
In-Reply-To: <BBE6C9EA-53B5-4EAA-A766-DAF241E7040D@freescale.com>
On Fri, 2006-04-14 at 15:00 -0500, Becky Bruce wrote:
> He's being sneaky - there's a copy of HID0 in the CR at this point
> from the caller, and bit 9 is the position for NAP.
It's a trick I learned from Darwin :) They do that regulary when code is
very cpu-feature dependant, like cache code for example, they put the
cpu features bitmask in CR and do branches based on individual bits of
it here or there.
Ben.
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Mel Gorman @ 2006-04-14 23:50 UTC (permalink / raw)
To: Nigel Cunningham
Cc: davej, tony.luck, Linux Memory Management List, ak, bob.picco,
Linux Kernel Mailing List, linuxppc-dev
In-Reply-To: <200604150917.10596.ncunningham@cyclades.com>
On Sat, 15 Apr 2006, Nigel Cunningham wrote:
> It looks to me like this code could be used by the software suspend code in
> our determinations of what pages to save
Potentially yes. Currently, the node map and related functions are marked
__init so they become unavailable but that is not set in stone.
>, particularly in the context of
> memory hotplug support.
Right now during memory hot-add, the memory is not registered with
add_active_range(), but it would be straight-forward to add the call to
add_memory() of each architecture that supported hotplug for example.
> Just some food for thought at the moment; I'll see if
> I can come up with a patch when I have some time, but it might help justify
> getting this merged.
>
Thanks
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Port Linux w/ mbxboot to PPCBoot system
From: Jessica Chen @ 2006-04-14 23:56 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am new to embedded system, I am studying ppcboot-1.1.5 and linux
kernel-2.4.4 that comes with an mpc852 base board, we want to modify it in
the future. In the build process, they use the zImage.initrd
(arch/ppc/mbxboot/zvmlinux.initrd) instead of the raw Linux kernel image
(arch/ppc/coffboot/vmlinux.gz) + separate initrd which is the way README
file suggested.
My question is:
since ppcboot is already running, what happens when I boot the kernel that
has old boot loader code in arch/ppc/mbxboot? Will some parameters be
overwritten? If not, why?
I am very tempted to follow the README to re-build the kernel with only
vmlinux.gz and port it, but I don't want to create any un-recoverable
results. So I am here to seek advice, maybe this is something obvious to
many people.
Thanks in advance,
Jessica Chen
^ permalink raw reply
* Re: Port Linux w/ mbxboot to PPCBoot system
From: Wolfgang Denk @ 2006-04-15 0:12 UTC (permalink / raw)
To: Jessica Chen; +Cc: linuxppc-embedded
In-Reply-To: <002701c6601f$15b27f30$9afea8c0@tcdomain.com>
Dear Jessica,
in message <002701c6601f$15b27f30$9afea8c0@tcdomain.com> you wrote:
>
> I am new to embedded system, I am studying ppcboot-1.1.5 and linux
> kernel-2.4.4 that comes with an mpc852 base board, we want to modify it in
Both PPCBoot and Linux 2.4.4 are *hoplessly* obsolete. It may be ok
to study this to understand the workings, but please don't even dream
of using it for any current work.
> the future. In the build process, they use the zImage.initrd
> (arch/ppc/mbxboot/zvmlinux.initrd) instead of the raw Linux kernel image
Somebody didn't know what he was doing, it seems.
> since ppcboot is already running, what happens when I boot the kernel that
> has old boot loader code in arch/ppc/mbxboot? Will some parameters be
> overwritten? If not, why?
The Linux bootstrap loader code (arch/ppc/mbxboot) will ignore the
parameteres passed by U-Boot, will set up is own (hardwired), and
duplicate some of the things that PPCboot did or would do.
> I am very tempted to follow the README to re-build the kernel with only
> vmlinux.gz and port it, but I don't want to create any un-recoverable
> results. So I am here to seek advice, maybe this is something obvious to
> many people.
Don't change anything. Look at it, then drop it. Start using current
code, i. e. a recent version of U-Boot and a recent Linux kernel.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Good morning. This is the telephone company. Due to repairs, we're
giving you advance notice that your service will be cut off indefi-
nitely at ten o'clock. That's two minutes from now.
^ permalink raw reply
* Re: patch for powerpc lparcfg.c
From: Carl Love @ 2006-04-15 0:16 UTC (permalink / raw)
To: Nathan Lynch, linuxppc-dev
In-Reply-To: <20060414175039.GD25138@localdomain>
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
Nathan Lynch:
Oops, lost the cc line the last time.
I wasn't aware that the partition name was already being printed in
the /proc/device-tree. Yes, my tool could use that entry. It just
means opening multiple locations to get all the information. I will go
ahead and use it since it is there.
The patch becomes a bit more academic. The question becomes, should the
partition name also be printed in /proc/ppc64/lparcfg along with the
rest of the partition information? Seems like a good idea to me since
it makes the information in lparcfg more complete. I will leave it up
to the maintainers to decide.
I have reattached the updated patch in case anyone cares.
Thanks for letting me know where I can get the partition name.
Carl Love
On Fri, 2006-04-14 at 12:50 -0500, Nathan Lynch wrote:
> You forgot to cc the list...
>
> Carl Love wrote:
> >
> > The intended consumer of this information is a tool that I am working
> > on. The tool prints the CPU utilization as a function of the
> > partition's processor entitlement, hypervisor call statistics (number of
> > calls, average call time, max call time, min call time) and partition
> > configuration information. Specifically, the -i option is to print the
> > partition information. The required information includes the partition
> > name. Most of the other required information comes from
> > the /proc/ppc64/lparcfg file. This seems like a logical place to
> > include the partition name.
>
> The partition name, if it exists, is already available at
> /proc/device-tree/ibm,partition-name. Any reason your tool couldn't
> use that?
[-- Attachment #2: linux-2.6.17-rc1-git8-lparcfg.patch --]
[-- Type: text/x-patch, Size: 1155 bytes --]
diff -rauN -X /home/carll/dontdiff linux-2.6.17-rc1-git8/arch/powerpc/kernel/lparcfg.c linux-2.6.17-rc1-git8-new/arch/powerpc/kernel/lparcfg.c
--- linux-2.6.17-rc1-git8/arch/powerpc/kernel/lparcfg.c 2006-04-13 12:25:11.000000000 -0700
+++ linux-2.6.17-rc1-git8-new/arch/powerpc/kernel/lparcfg.c 2006-04-14 09:24:12.000000000 -0700
@@ -340,6 +340,7 @@
struct device_node *rootdn;
const char *model = "";
const char *system_id = "";
+ const char *partition_name = NULL;
unsigned int *lp_index_ptr, lp_index = 0;
struct device_node *rtas_node;
int *lrdrp = NULL;
@@ -347,6 +348,8 @@
rootdn = find_path_device("/");
if (rootdn) {
model = get_property(rootdn, "model", NULL);
+ partition_name = get_property(rootdn,
+ "ibm,partition-name", NULL);
system_id = get_property(rootdn, "system-id", NULL);
lp_index_ptr = (unsigned int *)
get_property(rootdn, "ibm,partition-no", NULL);
@@ -360,6 +363,9 @@
seq_printf(m, "system_type=%s\n", model);
+ if (!NULL)
+ seq_printf(m, "partition_name=%s\n", partition_name);
+
seq_printf(m, "partition_id=%d\n", (int)lp_index);
rtas_node = find_path_device("/rtas");
^ permalink raw reply
* [PATCH 00/08] robust per_cpu allocation for modules - V2
From: Steven Rostedt @ 2006-04-15 3:10 UTC (permalink / raw)
To: LKML
Cc: Andrew Morton, linux-mips, linux-ia64, Martin Mares, spyro,
Joe Taylor, linuxppc-dev, paulus, SamRavnborg, bjornw,
Ingo Molnar, grundler, starvik, Linus Torvalds, Thomas Gleixner,
rth, Chris Zankel, tony.luck, Andi Kleen, ralf, Marc Gauthier,
lethal, schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145049535.1336.128.camel@localhost.localdomain>
This is version 2 of the percpu patch set.
Changes from version 1:
- Created a PERCPU_OFFSET variable to use in vmlinux.lds.h
(suggested by Sam Ravnborg)
- Added support for x86_64 (Steven Rostedt)
The support for x86_64 goes back to the asm-generic handling when both
CONFIG_SMP and CONFIG_MODULES are set. This is due to the fact that the
__per_cpu_offset array is no longer referenced in per_cpu, but instead a
per per_cpu variable is used to find the offset.
Again, the rest of the patches are only sent to the LKML.
Still I need help to port this to the rest of the architectures.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH 0/7] [RFC] Sizing zones and holes in an architecture independent manner V2
From: Nigel Cunningham @ 2006-04-14 23:17 UTC (permalink / raw)
To: Mel Gorman
Cc: davej, tony.luck, linux-mm, ak, bob.picco, linux-kernel,
linuxppc-dev
In-Reply-To: <20060412232036.18862.84118.sendpatchset@skynet>
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Hi Mel.
It looks to me like this code could be used by the software suspend code in
our determinations of what pages to save, particularly in the context of
memory hotplug support. Just some food for thought at the moment; I'll see if
I can come up with a patch when I have some time, but it might help justify
getting this merged.
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [2/2] POWERPC: Lower threshold for DART enablement to 1GB, V2
From: Muli Ben-Yehuda @ 2006-04-15 7:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <1145048275.4223.32.camel@localhost.localdomain>
On Sat, Apr 15, 2006 at 06:57:55AM +1000, Benjamin Herrenschmidt wrote:
> Not sure I ever heard about that... What chipsets ?
I'm not sure which IBM pSeries modesl have Calgary in them. Perhaps
Jon or Olof know?
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
^ permalink raw reply
* Re: 7447A strange problem with MSR:POW (WAS: can't boot 2.6.17-rc1)
From: Michael Schmitz @ 2006-04-15 11:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Becky Bruce, debian-powerpc
In-Reply-To: <17471.62187.774127.783000@cargo.ozlabs.ibm.com>
> > Actually, I think the problem is that the code linux is using to turn
> > on nap mode is not guaranteed to put the processor in nap mode by the
> > time the blr in ppc6xx_idle occurs.
>
> Thanks, Becky.
>
> This patch fixes it for me. Comments, anyone?
Works for me :-)
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox