* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Andi Kleen @ 2006-04-17 17:10 UTC (permalink / raw)
To: Nick Piggin
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, grundler, Steven Rostedt,
starvik, Linus Torvalds, Thomas Gleixner, rth, Chris Zankel,
tony.luck, LKML, ralf, Marc Gauthier, lethal, schwidefsky,
linux390, davem, parisc-linux
In-Reply-To: <4441ECE6.5010709@yahoo.com.au>
On Sunday 16 April 2006 09:06, Nick Piggin wrote:
> I still don't understand what the justification is for slowing down
> this critical bit of infrastructure for something that is only a
> problem in the -rt patchset, and even then only a problem when tracing
> is enabled.
There are actually problems outside -rt. e.g. the Xen kernel was running
into a near overflow and as more and more code is using per cpu variables
others might too.
I'm confident the problem can be solved without adding more variables
though - e.g. in the way rusty proposed.
-Andi
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Christoph Lameter @ 2006-04-17 16:55 UTC (permalink / raw)
To: kiran
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, Nick Piggin, grundler,
Steven Rostedt, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <4440855A.7040203@yahoo.com.au>
On Sat, 15 Apr 2006, Nick Piggin wrote:
> If I'm following you correctly, this adds another dependent load
> to a per-CPU data access, and from memory that isn't node-affine.
I am also concerned about that. Kiran has a patch to avoid allocpercpu
having to go through one level of indirection that I guess would no
longer work with this scheme.
> If so, I think people with SMP and NUMA kernels would care more
> about performance and scalability than the few k of memory this
> saves.
Right.
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Andreas Schwab @ 2006-04-17 13:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1145233812.9833.21.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Interesting... I would have expected that setup to work... Oh well... at
> this point, the best to do is to add support for your G5 to Johannes new
> snd-aoa
I agree. Unfortunately, the i2sbus probing already fails, due to
requesting a memory region that is already (partially) claimed by other
resources:
request_mem_region(80000000 - 80000fff, i2sbus control)
80000000-8007ffff : 0.80000000:mac-io
8000002c-8000002f : 0.0000004c:fans
80000030-80000033 : 0.0000004c:fans
80000034-80000037 : 0.0000004c:fans
8000004c-8000004f : 0.0000004c:fans
80000050-8000008a : 0.00000050:gpio
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: kernel access of bad area, sig: 11 ( mpc852t)
From: Akshay Mishra @ 2006-04-17 11:35 UTC (permalink / raw)
To: linuxppc-embedded
>> Hi,
>> Im having problem porting linux kernel 2.4.21 to our mpc852T custom
>> board.The kernel
>> panics randomly with sig 11.
>> The board boots up fine and we also get to the prompt.When we open 3-4
>> telnet sessions
>> and try to run some command the kernel panics.This is completely
>> random.Sometimes it
>> even panics before opening the telnet session.
>>
>> One of the oops dump is:
>>
>> ------------------------------------------------------------------------=
------------
\
>> -----------------------------------------
>> Oops: kernel access of bad area, sig: 11
>> NIP: C0019FD0 XER: 00000000 LR: C001A06C SP: C1C33AD0 REGS: c1c33a20
>> TRAP: 0300 Not tainted
>> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
>> DAR: 725F6578, DSISR: 0000000B
>> TASK =3D c1c32000[48] 'insmod' Last syscall: 5
>> last math 00000000 last altivec 00000000
>> GPR00: 7361726D C1C33AD0 C1C32000 00000000 C0113678 C0150000 C0150000
>> C014B210
>> GPR08: C014B210 C012D060 00000000 725F6578 04000024 00000000 00000000
>> 00000000
>> GPR16: 00000000 00000000 00000000 00000000 00001032 01C33BA0 00000000
>> C0000000
>> GPR24: C014BE38 C0150000 C0110000 C0110000 C0140000 00000001 00000000
>> 00000001
>> Call backtrace:
>> C001A0C8 C0016174 C0015FEC C0015CC0 C0005E38 C0004668 C1C33D10
>> C0004670 C004A380 C003FFD4 C00404D8 C0040AD4 C0040FF8 C00330D8
>> C00334AC C000443C 1006EF48 1001FCF0 1002023C 10003A18 100036A0
>> 300591AC 00000000
>> ------------------------------------------------------------------------=
------------
\
>> -----------------------------------------
>> The call trace back is of not much help because it is different on all
>> oops.
>> We are using u-boot 1-1-3.
>>
>> Thanks in advance.
>>
>You almost certainly have SDRAM problems. If you have thoroughly checked
>out the
>complete address range statically, remember that burst accesses will not
>occur until the
>cache is turned on, so your problem may be with bursting. But you can als=
o
>have severe
>problems like a missing address line and linux still run for a few seconds=
.
>
>Mark Chambers
We've checked the SDRAM. The timings (UPM) look fine. The problem
however is that linux does not hang until after a few processes are
started.
If we boot to linux and leave it as it is, everything is fine and the
board remains working. However each time a few processes (4-5 telnet
sessions for eg.) are started the system either panics or hangs (goes
dead).
Thanks in advance,
Akshay
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-17 11:33 UTC (permalink / raw)
To: Rusty Russell
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145256445.28600.34.camel@localhost.localdomain>
On Mon, 2006-04-17 at 16:47 +1000, Rusty Russell wrote:
>
> The arch would allocate a virtual memory hole for each CPU, and map
> pages as required (this is the simplest of several potential schemes).
> This gives the "same space between CPUs" property which is required for
> the ptr + per-cpu-offset scheme. An arch would supply functions like:
>
> /* Returns address of new memory chunk(s)
> * (add __per_cpu_offset to get virtual addresses). */
> unsigned long alloc_percpu_memory(unsigned long *size);
>
> /* Set by ia64 to reserve the first chunk for percpu vars
> * in modules only.
> #define __MODULE_RESERVE_FIRST_CHUNK
>
> And an allocator would work on top of these.
>
> I'm glad someone is looking at this again!
Hi Rusty, thanks for the input.
Arnd Bergmann also suggested doing the same thing. I've slept on this
thought last night and I'm starting to like it more and more. At least
it seems to be a better solution than some of the things that I've come
up with.
I'll start playing around a little and see what I can do with it. I
also need to start doing some other work too, so this might take a month
or two to get some results. So hopefully, I'll have another patch set
in June or July that will be more acceptable.
I'd like to thank all those that responded with ideas and criticisms.
It's been very helpful.
-- Steve
^ permalink raw reply
* RE: Watchdog on MPC82xx
From: Bastos Fernandez Alexandre @ 2006-04-17 8:31 UTC (permalink / raw)
To: 'Mike Rapoport', Bastos Fernandez Alexandre
Cc: linuxppc-embedded list
Mike,
I tested several times last week but it didn't work for me.
I had made the changes in U-boot as you say, but it keeped
reseting at the time. In fact, in the log_buf I can see
several printk's after setup_arch (where ppc_md.heartbeat)
is assigned, but the watchdog counter is not reloaded.
Which could be the difference? I am using ramdisk,
and a MPC8248 clocked at 100MHz, but I don't think
this will be the reason.
Now, someone has proposed me to try reloading WDT in
printk calls. I will test.
Best regards,
Alex
> Bastos Fernandez Alexandre wrote:
>
> >
> >So, any other idea? Is the WDT on MPC8248 usable at all?
> >
> >
> I used the watchdog timer on mpc8247 and mpc8271. The mpc8248 watchdog
> should be the same. I used ppc_md.heartbeat to write to the watchdog
> registers and it worked fine. Also, I've added WATCHDOG_RESET() to
> common/cmd_bootm.c in U-Boot just before the jump to kernel.
>
> >Thanks,
> >
> >Alex
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
> >
> >
>
>
> --
> Sincerely yours,
> Mike Rapoport
> -----------------------------------------------------------------
> CompuLab Ltd.
> Web: http://www.compulab.co.il
^ permalink raw reply
* about ppc <asm/string.h>
From: HappyPhot @ 2006-04-17 7:08 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Under linux kernel, the file /include/linux/string.h will include
<asm/string.h>.
But I didn't found "string.h" under "asm-ppc", my asm is link to asm-ppc
(CPU is ppc). This makes me compile some code failed.
(kernel version 2.6.x)
Anybody knows about this ? Why there is no string.h under "asm-ppc"
directory.
thanks a lot,
/Phot
^ permalink raw reply
* Re: Watchdog on MPC82xx
From: Mike Rapoport @ 2006-04-17 7:02 UTC (permalink / raw)
To: Bastos Fernandez Alexandre; +Cc: linuxppc-embedded list
In-Reply-To: <1144842264.443ce818d6822@webmail.televes.com:443>
Bastos Fernandez Alexandre wrote:
>
>So, any other idea? Is the WDT on MPC8248 usable at all?
>
>
I used the watchdog timer on mpc8247 and mpc8271. The mpc8248 watchdog
should be the same. I used ppc_md.heartbeat to write to the watchdog
registers and it worked fine. Also, I've added WATCHDOG_RESET() to
common/cmd_bootm.c in U-Boot just before the jump to kernel.
>Thanks,
>
>Alex
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
--
Sincerely yours,
Mike Rapoport
-----------------------------------------------------------------
CompuLab Ltd.
Web: http://www.compulab.co.il
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Rusty Russell @ 2006-04-17 6:47 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145194804.27407.103.camel@localhost.localdomain>
On Sun, 2006-04-16 at 09:40 -0400, Steven Rostedt wrote:
> The reason that this is done, is that the per_cpu macro cant know
> whether or not the per_cpu variable was declared in a kernel or in a
> module. So the __pre_cpu_offset[] array offset can't be used if the
> module allocation is in its own separate area. Remember that this offset
> array stores the difference from where the variable originally was and
> where it is now for each cpu.
Actually, the reason this is done is because the per_cpu_offset[] is
designed to be replaced by a register or an expression on archs which
care, and this is simple. The main problem is that so many archs want
different things, it's a very UN task to build infrastructure.
I have always recommended using the same scheme to implement real
dynamic per-cpu allocation (which would then replace the mini-allocator
inside the module code). In fact, I had such an implementation which I
reduced to the module case (dynamic per-cpu was too far-out at the
time).
The arch would allocate a virtual memory hole for each CPU, and map
pages as required (this is the simplest of several potential schemes).
This gives the "same space between CPUs" property which is required for
the ptr + per-cpu-offset scheme. An arch would supply functions like:
/* Returns address of new memory chunk(s)
* (add __per_cpu_offset to get virtual addresses). */
unsigned long alloc_percpu_memory(unsigned long *size);
/* Set by ia64 to reserve the first chunk for percpu vars
* in modules only.
#define __MODULE_RESERVE_FIRST_CHUNK
And an allocator would work on top of these.
I'm glad someone is looking at this again!
Rusty.
--
ccontrol: http://ozlabs.org/~rusty/ccontrol
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-17 2:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, rusty, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <200604170407.26111.arnd@arndb.de>
On Mon, 17 Apr 2006, Arnd Bergmann wrote:
> Am Monday 17 April 2006 02:45 schrieb Steven Rostedt:
> > > - does not work in real mode, so percpu data can't be used
> > > =C2=A0 inside exception handlers on some architectures.
> >
> > This is probably a big issue. =C2=A0I believe interrupt context in hrti=
mers
> > uses per_cpu variables.
>
> If it's just about hrtimers, it should be harmless, since they
> are run in softirq context. Even regular interrupt handlers are
> always called with paging enabled, otherwise you could not
> have them im modules.
Ah, you're right. You said exceptions, I'm thinking interrupts. I was a
little confused why it wouldn't work.
>
> > > - memory consumption is rather high when PAGE_SIZE is large
> >
> > That's also something that I'm trying to solve. =C2=A0To use the least =
amount
> > of memory and still have the performance.
> >
> > Now, I've also thought about allocating per_cpu and when a module is
> > loaded, reallocate more memory and copy it again. =C2=A0Use something l=
ike
> > the kstopmachine to sync the system so that the CPUS don't update any
> > per_cpu variables while this is happening, so that things can't get out
> > of sync.
>
> I guess this breaks if someone holds a pointer to a per-cpu variable
> while a module gets loaded.
>
Argh, good point, I didn't think about that. Hmm, this solution is
looking harder and harder. Darn, I was really hoping this could be a
little better in space savings and robustness. It's starting to seem
clearer that Rusty's little hack, may be the best solution.
If that's the case, I can at least take comfort in knowing that the time I
spent on this is documented in LKML archives, and perhaps can keep others
from spending the time too. That said, I haven't quite given up, and may
spend a couple more sleepless nights pondering this.
-- Steve
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Arnd Bergmann @ 2006-04-17 2:07 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, rusty, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145234750.27828.8.camel@localhost.localdomain>
Am Monday 17 April 2006 02:45 schrieb Steven Rostedt:
> > - does not work in real mode, so percpu data can't be used
> > =C2=A0 inside exception handlers on some architectures.
>
> This is probably a big issue. =C2=A0I believe interrupt context in hrtime=
rs
> uses per_cpu variables.
If it's just about hrtimers, it should be harmless, since they
are run in softirq context. Even regular interrupt handlers are
always called with paging enabled, otherwise you could not
have them im modules.
> > - memory consumption is rather high when PAGE_SIZE is large
>
> That's also something that I'm trying to solve. =C2=A0To use the least am=
ount
> of memory and still have the performance.
>
> Now, I've also thought about allocating per_cpu and when a module is
> loaded, reallocate more memory and copy it again. =C2=A0Use something like
> the kstopmachine to sync the system so that the CPUS don't update any
> per_cpu variables while this is happening, so that things can't get out
> of sync.
I guess this breaks if someone holds a pointer to a per-cpu variable
while a module gets loaded.
Arnd <><
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Paul Collins @ 2006-04-17 0:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <874q0t11lz.fsf@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
>> On Mon, 2006-04-17 at 00:39 +1000, Paul Collins wrote:
>>> With Linus's current git plus the boot fix and some unrelated patches
>>> (console font and bluetooth) sound no longer seems to work (nothing in
>>> /proc/asound/cards), although snd-powermac loaded without complaint.
>>> Is this a known problem?
>>
>> Load i2c-powermac before snd-powermac
>
> Like Andreas, I have =y and =m for those.
Still doesn't work with both =m.
Anyway I guess I'll look into this snd-aoa thing.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-17 0:45 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, rusty, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <200604161734.20256.arnd@arndb.de>
On Sun, 2006-04-16 at 17:34 +0200, Arnd Bergmann wrote:
> On Sunday 16 April 2006 15:40, Steven Rostedt wrote:
> > I'll think more about this, but maybe someone else has some crazy ideas
> > that can find a solution to this that is both fast and robust.
>
> Ok, you asked for a crazy idea, you're going to get it ;-)
>
> You could take a fixed range from the vmalloc area (e.g. 1MB per cpu)
> and use that to remap pages on demand when you need per cpu data.
>
> #define PER_CPU_BASE 0xe000000000000000UL /* arch dependant */
> #define PER_CPU_SHIFT 0x100000UL
> #define __per_cpu_offset(__cpu) (PER_CPU_BASE + PER_CPU_STRIDE * (__cpu))
> #define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset(cpu)))
> #define __get_cpu_var(var) per_cpu(var, smp_processor_id())
>
> This is a lot like the current sparc64 implementation already is.
>
Hmm, interesting idea.
> The tricky part here is the remapping of pages. You'd need to
> alloc_pages_node() new pages whenever the already reserved space is
> not enough for the module you want to load and then map_vm_area()
> them into the space reserved for them.
>
> Advantages of this solution are:
> - no dependant load access for per_cpu()
> - might be flexible enough to implement a faster per_cpu_ptr()
> - can be combined with ia64-style per-cpu remapping
>
> Disadvantages are:
> - you can't use huge tlbs for mapping per cpu data like the
> regular linear mapping -> may be slower on some archs
> - does not work in real mode, so percpu data can't be used
> inside exception handlers on some architectures.
This is probably a big issue. I believe interrupt context in hrtimers
uses per_cpu variables.
> - memory consumption is rather high when PAGE_SIZE is large
That's also something that I'm trying to solve. To use the least amount
of memory and still have the performance.
Now, I've also thought about allocating per_cpu and when a module is
loaded, reallocate more memory and copy it again. Use something like
the kstopmachine to sync the system so that the CPUS don't update any
per_cpu variables while this is happening, so that things can't get out
of sync.
This shouldn't be too much of an issue, since this would only be done
when a module is being loaded, and that is a user event that doesn't
happen often.
We would still need to use the method of keeping track of what is
allocated and freed, so that when a module is unloaded, we can still
free the area in the per_cpu data. And reallocate that area if a module
is added that uses less or the same amount of memory as what was freed.
-- Steve
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Paul Collins @ 2006-04-17 0:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1145220183.9833.9.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> On Mon, 2006-04-17 at 00:39 +1000, Paul Collins wrote:
>> With Linus's current git plus the boot fix and some unrelated patches
>> (console font and bluetooth) sound no longer seems to work (nothing in
>> /proc/asound/cards), although snd-powermac loaded without complaint.
>> Is this a known problem?
>
> Load i2c-powermac before snd-powermac
Like Andreas, I have =y and =m for those.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Benjamin Herrenschmidt @ 2006-04-17 0:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <je3bgdhwre.fsf@sykes.suse.de>
On Mon, 2006-04-17 at 02:27 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > i2c-powermac is built-in ans snd-powermac is a module or they are both
> > built-in ?
>
> The former.
Interesting... I would have expected that setup to work... Oh well... at
this point, the best to do is to add support for your G5 to Johannes new
snd-aoa
Ben.
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Andreas Schwab @ 2006-04-17 0:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1145231658.9833.17.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> i2c-powermac is built-in ans snd-powermac is a module or they are both
> built-in ?
The former.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Benjamin Herrenschmidt @ 2006-04-16 23:54 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <je7j5phz9j.fsf@sykes.suse.de>
On Mon, 2006-04-17 at 01:33 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>
> > Same reply... load i2c-powermac before snd-powermac.
>
> It's builtin.
i2c-powermac is built-in ans snd-powermac is a module or they are both
built-in ?
Ben.
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Andreas Schwab @ 2006-04-16 23:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1145220233.9833.11.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
> Same reply... load i2c-powermac before snd-powermac.
It's builtin.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Benjamin Herrenschmidt @ 2006-04-16 20:43 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <je1wvxo70l.fsf@sykes.suse.de>
On Sun, 2006-04-16 at 17:49 +0200, Andreas Schwab wrote:
> Paul Collins <paul@briny.ondioline.org> writes:
>
> > With Linus's current git plus the boot fix and some unrelated patches
> > (console font and bluetooth) sound no longer seems to work (nothing in
> > /proc/asound/cards), although snd-powermac loaded without complaint.
> > Is this a known problem?
>
> Sound doesn't work here on PowerMac7,3 either, it even oopses during
> module loading.
Same reply... load i2c-powermac before snd-powermac. It's a bug in the
sound driver, but I can't be bothered fixing it at this point, better to
concentrate on the new snd-aoa and adapting it to work on all machines.
Ben.
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Benjamin Herrenschmidt @ 2006-04-16 20:43 UTC (permalink / raw)
To: Paul Collins; +Cc: linuxppc-dev
In-Reply-To: <878xq51t61.fsf@briny.internal.ondioline.org>
On Mon, 2006-04-17 at 00:39 +1000, Paul Collins wrote:
> With Linus's current git plus the boot fix and some unrelated patches
> (console font and bluetooth) sound no longer seems to work (nothing in
> /proc/asound/cards), although snd-powermac loaded without complaint.
> Is this a known problem?
Load i2c-powermac before snd-powermac
Ben.
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Tony Luck @ 2006-04-16 18:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, rusty, Steven Rostedt, starvik, Linus Torvalds,
Thomas Gleixner, rth, Chris Zankel, LKML, ralf, Marc Gauthier,
lethal, schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <200604161734.20256.arnd@arndb.de>
On 4/16/06, Arnd Bergmann <arnd@arndb.de> wrote:
> #define PER_CPU_BASE 0xe000000000000000UL /* arch dependant */
On ia64 the percpu area is at 0xffffffffffff0000 so that it can be
addressed without tying up another register (all percpu addresses
are small negative offsets from "r0"). When David Mosberger
chose this address he said that gcc 4 would actually make
ue of this, but I haven't checked the generated code to see
whether it really is doing so.
-Tony
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Steven Rostedt @ 2006-04-16 16:06 UTC (permalink / raw)
To: Nick Piggin
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, grundler, starvik,
Linus Torvalds, Thomas Gleixner, rth, Chris Zankel, tony.luck,
LKML, ralf, Marc Gauthier, lethal, schwidefsky, linux390, davem,
parisc-linux
In-Reply-To: <4441ECE6.5010709@yahoo.com.au>
On Sun, 2006-04-16 at 17:06 +1000, Nick Piggin wrote:
> Steven Rostedt wrote:
> > On Sun, 16 Apr 2006, Nick Piggin wrote:
>
> >>Why is your module using so much per-cpu memory, anyway?
> >
> >
> > Wasn't my module anyway. The problem appeared in the -rt patch set, when
> > tracing was turned on. Some module was affected, and grew it's per_cpu
> > size by quite a bit. In fact we had to increase PERCPU_ENOUGH_ROOM by up
> > to something like 300K.
>
> Well that's easy then, just configure PERCPU_ENOUGH_ROOM to be larger
> when tracing is on in the -rt patchset? Or use alloc_percpu for the
> tracing data?
>
Yeah, we already know this. The -rt patch was what showed the problem,
not the reason I was writing these patches.
> >>I don't think it would have been hard for the original author to make
> >>it robust... just not both fast and robust. PERCPU_ENOUGH_ROOM seems
> >>like an ugly hack at first glance, but I'm fairly sure it was a result
> >>of design choices.
> >
> > Yeah, and I discovered the reasons for those choices as I worked on this.
> > I've put a little more thought into this and still think there's a
> > solution to not slow things down.
> >
> > Since the per_cpu_offset section is still smaller than the
> > PERCPU_ENOUGH_ROOM and robust, I could still copy it into a per cpu memory
> > field, and even add the __per_cpu_offset to it. This would still save
> > quite a bit of space.
>
> Well I don't think making it per-cpu would help much (presumably it
> is not going to be written to very frequently) -- I guess it would
> be a small advantage on NUMA. The main problem is the extra load in
> the fastpath.
>
> You can't start the next load until the results of the first come
> back.
Yep, you're right here, and it bothers me too that this slows down
performance.
>
> > So now I'm asking for advice on some ideas that can be a work around to
> > keep the robustness and speed.
> >
> > Is there a way (for archs that support it) to allocate memory in a per cpu
> > manner. So each CPU would have its own variable table in the memory that
> > is best of it. Then have a field (like the pda in x86_64) to point to
> > this section, and use the linker offsets to index and find the per_cpu
> > variables.
> >
> > So this solution still has one more redirection than the current solution
> > (per_cpu_offset__##var -> __per_cpu_offset -> actual_var where as the
> > current solution is __per_cpu_offset -> actual_var), but all the loads
> > would be done from memory that would only be specified for a particular
> > CPU.
> >
> > The generic case would still be the same as the patches I already sent,
> > but the archs that can support it, can have something like the above.
> >
> > Would something like that be acceptible?
>
> I still don't understand what the justification is for slowing down
> this critical bit of infrastructure for something that is only a
> problem in the -rt patchset, and even then only a problem when tracing
> is enabled.
>
It's because I'm anal retentive :-)
I noticed that the current solution is somewhat a hack, and thought
maybe it could be done cleaner. Perhaps I'm wrong and the hack _is_ the
best solution, but it doesn't hurt in trying to improve it. Or the very
least, prove that the current solution is the way to go.
I'm not trying to solve an issue with the -rt patch and tracing, I'm
just trying to make Linux a little more efficient in saving space. And
you may be right that we cant do that without hurting performance, and
thus we keep things as is. But I don't want to give up without a fight
and miss something that can solve all this and keep Linux the best OS on
the market! (not to say that it isn't even with the current solution)
-- Steve
^ permalink raw reply
* Re: PowerBook5,4 -- no sound?
From: Andreas Schwab @ 2006-04-16 15:49 UTC (permalink / raw)
To: Paul Collins; +Cc: linuxppc-dev
In-Reply-To: <878xq51t61.fsf@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> With Linus's current git plus the boot fix and some unrelated patches
> (console font and bluetooth) sound no longer seems to work (nothing in
> /proc/asound/cards), although snd-powermac loaded without complaint.
> Is this a known problem?
Sound doesn't work here on PowerMac7,3 either, it even oopses during
module loading.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Arnd Bergmann @ 2006-04-16 15:34 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev,
Paul Mackerras, benedict.gaster, bjornw, Ingo Molnar, Nick Piggin,
grundler, rusty, starvik, Linus Torvalds, Thomas Gleixner, rth,
Chris Zankel, tony.luck, LKML, ralf, Marc Gauthier, lethal,
schwidefsky, linux390, davem, parisc-linux
In-Reply-To: <1145194804.27407.103.camel@localhost.localdomain>
On Sunday 16 April 2006 15:40, Steven Rostedt wrote:
> I'll think more about this, but maybe someone else has some crazy ideas
> that can find a solution to this that is both fast and robust.
Ok, you asked for a crazy idea, you're going to get it ;-)
You could take a fixed range from the vmalloc area (e.g. 1MB per cpu)
and use that to remap pages on demand when you need per cpu data.
#define PER_CPU_BASE 0xe000000000000000UL /* arch dependant */
#define PER_CPU_SHIFT 0x100000UL
#define __per_cpu_offset(__cpu) (PER_CPU_BASE + PER_CPU_STRIDE * (__cpu))
#define per_cpu(var, cpu) (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset(cpu)))
#define __get_cpu_var(var) per_cpu(var, smp_processor_id())
This is a lot like the current sparc64 implementation already is.
The tricky part here is the remapping of pages. You'd need to
alloc_pages_node() new pages whenever the already reserved space is
not enough for the module you want to load and then map_vm_area()
them into the space reserved for them.
Advantages of this solution are:
- no dependant load access for per_cpu()
- might be flexible enough to implement a faster per_cpu_ptr()
- can be combined with ia64-style per-cpu remapping
Disadvantages are:
- you can't use huge tlbs for mapping per cpu data like the
regular linear mapping -> may be slower on some archs
- does not work in real mode, so percpu data can't be used
inside exception handlers on some architectures.
- memory consumption is rather high when PAGE_SIZE is large
Arnd <><
^ permalink raw reply
* Re: [PATCH 00/05] robust per_cpu allocation for modules
From: Nick Piggin @ 2006-04-16 7:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Andrew Morton, linux-mips, David Mosberger-Tang, linux-ia64,
Martin Mares, spyro, Joe Taylor, Andi Kleen, linuxppc-dev, paulus,
benedict.gaster, bjornw, Ingo Molnar, grundler, starvik,
Linus Torvalds, Thomas Gleixner, rth, Chris Zankel, tony.luck,
LKML, ralf, Marc Gauthier, lethal, schwidefsky, linux390, davem,
parisc-linux
In-Reply-To: <Pine.LNX.4.58.0604152323560.16853@gandalf.stny.rr.com>
Steven Rostedt wrote:
> On Sun, 16 Apr 2006, Nick Piggin wrote:
>>Why is your module using so much per-cpu memory, anyway?
>
>
> Wasn't my module anyway. The problem appeared in the -rt patch set, when
> tracing was turned on. Some module was affected, and grew it's per_cpu
> size by quite a bit. In fact we had to increase PERCPU_ENOUGH_ROOM by up
> to something like 300K.
Well that's easy then, just configure PERCPU_ENOUGH_ROOM to be larger
when tracing is on in the -rt patchset? Or use alloc_percpu for the
tracing data?
>>I don't think it would have been hard for the original author to make
>>it robust... just not both fast and robust. PERCPU_ENOUGH_ROOM seems
>>like an ugly hack at first glance, but I'm fairly sure it was a result
>>of design choices.
>
> Yeah, and I discovered the reasons for those choices as I worked on this.
> I've put a little more thought into this and still think there's a
> solution to not slow things down.
>
> Since the per_cpu_offset section is still smaller than the
> PERCPU_ENOUGH_ROOM and robust, I could still copy it into a per cpu memory
> field, and even add the __per_cpu_offset to it. This would still save
> quite a bit of space.
Well I don't think making it per-cpu would help much (presumably it
is not going to be written to very frequently) -- I guess it would
be a small advantage on NUMA. The main problem is the extra load in
the fastpath.
You can't start the next load until the results of the first come
back.
> So now I'm asking for advice on some ideas that can be a work around to
> keep the robustness and speed.
>
> Is there a way (for archs that support it) to allocate memory in a per cpu
> manner. So each CPU would have its own variable table in the memory that
> is best of it. Then have a field (like the pda in x86_64) to point to
> this section, and use the linker offsets to index and find the per_cpu
> variables.
>
> So this solution still has one more redirection than the current solution
> (per_cpu_offset__##var -> __per_cpu_offset -> actual_var where as the
> current solution is __per_cpu_offset -> actual_var), but all the loads
> would be done from memory that would only be specified for a particular
> CPU.
>
> The generic case would still be the same as the patches I already sent,
> but the archs that can support it, can have something like the above.
>
> Would something like that be acceptible?
I still don't understand what the justification is for slowing down
this critical bit of infrastructure for something that is only a
problem in the -rt patchset, and even then only a problem when tracing
is enabled.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ 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