* Re: Trouble with 2.6.16 on ppc8xx ?
From: Marcelo Tosatti @ 2006-04-17 21:52 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200604141050.56757.david.jander@protonic.nl>
Hi David,
On Fri, Apr 14, 2006 at 10:50:56AM +0200, David Jander wrote:
>
> Hi all,
>
> I just cg-update'd to the HEAD of the denx 2.6.x kernel tree (2.6.16 as
> released).
Is it a vanilla 2.6.16?
> Our board-support stuff was succesfully moved along from 2.6.14 (when
> everything but the SCC3 and SCC4 uarts worked just fine).
> I compiled a kernel without any special drivers, just console on ttyCPM0, but
> after "Uncompressing Kernel Image ... OK" there is no more output and no
> further activity on ethernet (it should boot from nfs-root) or any other
> device.
>
> After "cg-seek DENX-v2.6.15; make clean uImage", it works again (everything
> seems fine, system boots).
>
> Our board is based on a MPC852T and until now we used "MPC86X" as the
> BOARD_CHIP_NAME and it worked just fine with 2.6.14 and 2.6.15, but not with
> 2.6.16 as described above.
>
> When doing "cg-diff" and carfully examining it's output, I can only see our
> board-support stuff (not very much, not very special) and some custom drivers
> that are disabled anyway.
>
> Any clue about where to start looking?
>
> I didn't find any suspicious changes in arch/ppc/mm, arch/ppc/syslib and
> arch/ppc/kernel. Neither in drivers/serial/cpm_uart.
>
> Which change from 2.6.15 to 2.6.16 could have broken 8xx support for us?
>
> Is there perhaps a known issue with 2.6.16 and ppc8xx I am unaware of?
2.6.16 working fine over here... What's your .config?
[root@CAS root]# cat /proc/cpuinfo
processor : 0
cpu : 8xx
clock : 48MHz
bus clock : 48MHz
revision : 0.0 (pvr 0050 0000)
bogomips : 47.71
[root@CAS root]# uname -a
Linux CAS 2.6.16 #1 Thu Apr 13 11:08:03 PDT 2006 ppc unknown
^ permalink raw reply
* Re: about ppc <asm/string.h>
From: Becky Bruce @ 2006-04-17 18:52 UTC (permalink / raw)
To: HappyPhot; +Cc: linuxppc-embedded
In-Reply-To: <026801c661ed$bcb352d0$0760120a@photon>
Hi!
There's no string.h in include/asm-ppc because this is one of the
header files that has been merged between 32 and 64-bit powerpc. It
now lives in include/asm-powerpc with all the other merged headers.
Only headers specific to 32-bit ppc have been left in include/asm-
ppc. For a kernel build with ARCH=ppc, the build uses headers from
both include/asm-ppc and include/asm-powerpc. This is accomplished
through the use of a temporary include directory that is created in
the arch dir. Check out arch/ppc/Makefile for details.
Cheers,
-Becky
On Apr 17, 2006, at 2:08 AM, HappyPhot wrote:
> 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
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH] ppc64-soft-reset-fixes
From: David Wilder @ 2006-04-17 17:58 UTC (permalink / raw)
To: fastboot, linuxppc-dev, akpm, Haren Myneni
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
This is a reposting of a patch formally named
kdump-ppc64-soft-reset-fixes.patch posted:
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/021958.html
With cleanup suggested by Andrew's posting:
http://ozlabs.org/pipermail/linuxppc-dev/2006-April/021959.html
Description:
- For the crash scenario, when a CPU hangs with interrupts disabled and
the other CPUs panic or user invoked kdump boot using sysrq-c. In this
case, the hung CPU can not be stopped and causes the kdump boot not
successful. This case can be treated as complete system hang and asks
the user to activate soft-reset if all secondary CPUs are not stopped.
Regards
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: ppc64-soft-reset-fixes.patch --]
[-- Type: text/x-patch, Size: 10027 bytes --]
- For the crash scenario, when a CPU hangs with interrupts disabled and the other CPUs panic or user invoked kdump boot using sysrq-c. In this case, the hung CPU can not be stopped and causes the kdump boot not successful. This case can be treated as complete system hang and asks the user to activate soft-reset if all secondary CPUs are not stopped.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: David Wilder <dwilder@us.ibm.com>
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 778f22f..20ef5d2 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -23,9 +23,11 @@
#include <linux/elfcore.h>
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/irq.h>
#include <asm/processor.h>
#include <asm/machdep.h>
+#include <asm/kexec.h>
#include <asm/kdump.h>
#include <asm/lmb.h>
#include <asm/firmware.h>
@@ -40,6 +42,7 @@
/* This keeps a track of which one is crashing cpu. */
int crashing_cpu = -1;
+static cpumask_t cpus_in_crash = CPU_MASK_NONE;
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
@@ -97,34 +100,66 @@ static void crash_save_this_cpu(struct p
}
#ifdef CONFIG_SMP
-static atomic_t waiting_for_crash_ipi;
+static atomic_t enter_on_soft_reset = ATOMIC_INIT(0);
void crash_ipi_callback(struct pt_regs *regs)
{
int cpu = smp_processor_id();
- if (cpu == crashing_cpu)
- return;
-
if (!cpu_online(cpu))
return;
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 1);
-
local_irq_disable();
+ if (!cpu_isset(cpu, cpus_in_crash))
+ crash_save_this_cpu(regs, cpu);
+ cpu_set(cpu, cpus_in_crash);
- crash_save_this_cpu(regs, cpu);
- atomic_dec(&waiting_for_crash_ipi);
+ /*
+ * Entered via soft-reset - could be the kdump
+ * process is invoked using soft-reset or user activated
+ * it if some CPU did not respond to an IPI.
+ * For soft-reset, the secondary CPU can enter this func
+ * twice. 1 - using IPI, and 2. soft-reset.
+ * Tell the kexec CPU that entered via soft-reset and ready
+ * to go down.
+ */
+ if (cpu_isset(cpu, cpus_in_sr)) {
+ cpu_clear(cpu, cpus_in_sr);
+ atomic_inc(&enter_on_soft_reset);
+ }
+
+ /*
+ * Starting the kdump boot.
+ * This barrier is needed to make sure that all CPUs are stopped.
+ * If not, soft-reset will be invoked to bring other CPUs.
+ */
+ while (!cpu_isset(crashing_cpu, cpus_in_crash))
+ cpu_relax();
+
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 1);
kexec_smp_wait();
/* NOTREACHED */
}
-static void crash_kexec_prepare_cpus(void)
+/*
+ * Wait until all CPUs are entered via soft-reset.
+ */
+static void crash_soft_reset_check(int cpu)
+{
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+
+ cpu_clear(cpu, cpus_in_sr);
+ while (atomic_read(&enter_on_soft_reset) != ncpus)
+ cpu_relax();
+}
+
+
+static void crash_kexec_prepare_cpus(int cpu)
{
unsigned int msecs;
- atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
crash_send_ipi(crash_ipi_callback);
smp_wmb();
@@ -132,14 +167,13 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: Until we will have the way to stop other CPUSs reliabally,
* the crash CPU will send an IPI and wait for other CPUs to
- * respond. If not, proceed the kexec boot even though we failed to
- * capture other CPU states.
+ * respond.
* Delay of at least 10 seconds.
*/
- printk(KERN_ALERT "Sending IPI to other cpus...\n");
+ printk(KERN_EMERG "Sending IPI to other cpus...\n");
msecs = 10000;
- while ((atomic_read(&waiting_for_crash_ipi) > 0) && (--msecs > 0)) {
- barrier();
+ while ((cpus_weight(cpus_in_crash) < ncpus) && (--msecs > 0)) {
+ cpu_relax();
mdelay(1);
}
@@ -148,18 +182,71 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: In case if we do not get all CPUs, one possibility: ask the
* user to do soft reset such that we get all.
- * IPI handler is already set by the panic cpu initially. Therefore,
- * all cpus could invoke this handler from die() and the panic CPU
- * will call machine_kexec() directly from this handler to do
- * kexec boot.
- */
- if (atomic_read(&waiting_for_crash_ipi))
- printk(KERN_ALERT "done waiting: %d cpus not responding\n",
- atomic_read(&waiting_for_crash_ipi));
+ * Soft-reset will be used until better mechanism is implemented.
+ */
+ if (cpus_weight(cpus_in_crash) < ncpus) {
+ printk(KERN_EMERG "done waiting: %d cpu(s) not responding\n",
+ ncpus - cpus_weight(cpus_in_crash));
+ printk(KERN_EMERG "Activate soft-reset to stop other cpu(s)\n");
+ cpus_in_sr = CPU_MASK_NONE;
+ atomic_set(&enter_on_soft_reset, 0);
+ while (cpus_weight(cpus_in_crash) < ncpus)
+ cpu_relax();
+ }
+ /*
+ * Make sure all CPUs are entered via soft-reset if the kdump is
+ * invoked using soft-reset.
+ */
+ if (cpu_isset(cpu, cpus_in_sr))
+ crash_soft_reset_check(cpu);
/* Leave the IPI callback set */
}
+
+/*
+ * This function will be called by secondary cpus or by kexec cpu
+ * if soft-reset is activated to stop some CPUs.
+ */
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ int cpu = smp_processor_id();
+ unsigned long flags;
+ int msecs = 5;
+
+ local_irq_save(flags);
+ /* Wait 5ms if the kexec CPU is not entered yet. */
+ while (crashing_cpu < 0) {
+ if (--msecs < 0) {
+ /*
+ * Either kdump image is not loaded or
+ * kdump process is not started - Probably xmon
+ * exited using 'x'(exit and recover) or
+ * kexec_should_crash() failed for all running tasks.
+ */
+ cpu_clear(cpu, cpus_in_sr);
+ local_irq_restore(flags);
+ return;
+ }
+ mdelay(1);
+ cpu_relax();
+ }
+ if (cpu == crashing_cpu) {
+ /*
+ * Panic CPU will enter this func only via soft-reset.
+ * Wait until all secondary CPUs entered and
+ * then start kexec boot.
+ */
+ crash_soft_reset_check(cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
+ machine_kexec(kexec_crash_image);
+ /* NOTREACHED */
+ }
+ crash_ipi_callback(regs);
+}
+
#else
-static void crash_kexec_prepare_cpus(void)
+static void crash_kexec_prepare_cpus(int cpu)
{
/*
* move the secondarys to us so that we can copy
@@ -170,6 +257,10 @@ static void crash_kexec_prepare_cpus(voi
smp_release_cpus();
}
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ cpus_in_sr = CPU_MASK_NONE;
+}
#endif
void default_machine_crash_shutdown(struct pt_regs *regs)
@@ -185,15 +276,14 @@ void default_machine_crash_shutdown(stru
* The kernel is broken so disable interrupts.
*/
local_irq_disable();
-
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 0);
-
/*
* Make a note of crashing cpu. Will be used in machine_kexec
* such that another IPI will not be sent.
*/
crashing_cpu = smp_processor_id();
- crash_kexec_prepare_cpus();
crash_save_this_cpu(regs, crashing_cpu);
+ crash_kexec_prepare_cpus(crashing_cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 064a525..ad6500e 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -51,9 +51,13 @@
#include <asm/firmware.h>
#include <asm/processor.h>
#endif
+#include <asm/kexec.h>
#ifdef CONFIG_PPC64 /* XXX */
#define _IO_BASE pci_io_base
+#ifdef CONFIG_KEXEC
+cpumask_t cpus_in_sr = CPU_MASK_NONE;
+#endif
#endif
#ifdef CONFIG_DEBUGGER
@@ -96,7 +100,7 @@ static DEFINE_SPINLOCK(die_lock);
int die(const char *str, struct pt_regs *regs, long err)
{
- static int die_counter, crash_dump_start = 0;
+ static int die_counter;
if (debugger(regs))
return 1;
@@ -128,22 +132,12 @@ int die(const char *str, struct pt_regs
print_modules();
show_regs(regs);
bust_spinlocks(0);
-
- if (!crash_dump_start && kexec_should_crash(current)) {
- crash_dump_start = 1;
- spin_unlock_irq(&die_lock);
- crash_kexec(regs);
- /* NOTREACHED */
- }
spin_unlock_irq(&die_lock);
- if (crash_dump_start)
- /*
- * Only for soft-reset: Other CPUs will be responded to an IPI
- * sent by first kexec CPU.
- */
- for(;;)
- ;
+ if (kexec_should_crash(current))
+ crash_kexec(regs);
+ crash_kexec_secondary(regs);
+
if (in_interrupt())
panic("Fatal exception in interrupt");
@@ -205,6 +199,10 @@ void system_reset_exception(struct pt_re
if (ppc_md.system_reset_exception(regs))
return;
}
+
+#ifdef CONFIG_KEXEC
+ cpu_set(smp_processor_id(), cpus_in_sr);
+#endif
die("System Reset", regs, SIGABRT);
diff --git a/include/asm-powerpc/kexec.h b/include/asm-powerpc/kexec.h
index 6a2af2f..82097b3 100644
--- a/include/asm-powerpc/kexec.h
+++ b/include/asm-powerpc/kexec.h
@@ -114,6 +114,7 @@ extern void kexec_smp_wait(void); /* get
extern void __init kexec_setup(void);
extern int crashing_cpu;
extern void crash_send_ipi(void (*crash_ipi_callback)(struct pt_regs *));
+extern cpumask_t cpus_in_sr;
#endif /* __powerpc64 __ */
struct kimage;
@@ -123,8 +124,10 @@ extern int default_machine_kexec_prepare
extern void default_machine_crash_shutdown(struct pt_regs *regs);
extern void machine_kexec_simple(struct kimage *image);
-
+extern void crash_kexec_secondary(struct pt_regs *regs);
#endif /* ! __ASSEMBLY__ */
+#else
+static inline void crash_kexec_secondary(struct pt_regs *regs) { }
#endif /* CONFIG_KEXEC */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_KEXEC_H */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index cfb3410..6427949 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -106,6 +106,7 @@ extern struct page *kimage_alloc_control
extern void crash_kexec(struct pt_regs *);
int kexec_should_crash(struct task_struct *);
extern struct kimage *kexec_image;
+extern struct kimage *kexec_crash_image;
#define KEXEC_ON_CRASH 0x00000001
#define KEXEC_ARCH_MASK 0xffff0000
^ permalink raw reply related
* 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
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