It seems most problems with 4k stacks are already resolved at least
in -mm.
I'd like to see this patch to always use 4k stacks in -mm now for
finding any remaining problems before submitting this patch for Linus'
tree.
Signed-off-by: Adrian Bunk <[email protected]>
Acked-by: Arjan van de Ven <[email protected]>
---
This patch was already sent on:
- 5 Dec 2005
- 30 Nov 2005
- 23 Nov 2005
- 14 Nov 2005
arch/i386/Kconfig.debug | 10 ----------
arch/i386/kernel/irq.c | 10 ----------
include/asm-i386/irq.h | 11 +++--------
include/asm-i386/module.h | 8 +-------
include/asm-i386/thread_info.h | 6 +-----
5 files changed, 5 insertions(+), 40 deletions(-)
--- linux-2.6.14-mm2-full/arch/i386/Kconfig.debug.old 2005-11-14 01:30:54.000000000 +0100
+++ linux-2.6.14-mm2-full/arch/i386/Kconfig.debug 2005-11-14 01:31:06.000000000 +0100
@@ -52,16 +52,6 @@
portion of the kernel code won't be covered by a 2MB TLB anymore.
If in doubt, say "N".
-config 4KSTACKS
- bool "Use 4Kb for kernel stacks instead of 8Kb"
- depends on DEBUG_KERNEL
- help
- If you say Y here the kernel will use a 4Kb stacksize for the
- kernel stack attached to each process/thread. This facilitates
- running more threads on a system and also reduces the pressure
- on the VM subsystem for higher order allocations. This option
- will also use IRQ stacks to compensate for the reduced stackspace.
-
config X86_FIND_SMP_CONFIG
bool
depends on X86_LOCAL_APIC || X86_VOYAGER
--- linux-2.6.14-mm2-full/include/asm-i386/irq.h.old 2005-11-14 01:31:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/irq.h 2005-11-14 01:31:29.000000000 +0100
@@ -27,14 +27,9 @@
# define ARCH_HAS_NMI_WATCHDOG /* See include/linux/nmi.h */
#endif
-#ifdef CONFIG_4KSTACKS
- extern void irq_ctx_init(int cpu);
- extern void irq_ctx_exit(int cpu);
-# define __ARCH_HAS_DO_SOFTIRQ
-#else
-# define irq_ctx_init(cpu) do { } while (0)
-# define irq_ctx_exit(cpu) do { } while (0)
-#endif
+extern void irq_ctx_init(int cpu);
+extern void irq_ctx_exit(int cpu);
+#define __ARCH_HAS_DO_SOFTIRQ
#ifdef CONFIG_IRQBALANCE
extern int irqbalance_disable(char *str);
--- linux-2.6.14-mm2-full/include/asm-i386/thread_info.h.old 2005-11-14 01:31:45.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/thread_info.h 2005-11-14 01:32:11.000000000 +0100
@@ -53,11 +53,7 @@
#endif
#define PREEMPT_ACTIVE 0x10000000
-#ifdef CONFIG_4KSTACKS
-#define THREAD_SIZE (4096)
-#else
-#define THREAD_SIZE (8192)
-#endif
+#define THREAD_SIZE (4096)
#define STACK_WARN (THREAD_SIZE/8)
/*
--- linux-2.6.14-mm2-full/include/asm-i386/module.h.old 2005-11-14 01:32:18.000000000 +0100
+++ linux-2.6.14-mm2-full/include/asm-i386/module.h 2005-11-14 01:32:42.000000000 +0100
@@ -64,12 +64,6 @@
#define MODULE_REGPARM ""
#endif
-#ifdef CONFIG_4KSTACKS
-#define MODULE_STACKSIZE "4KSTACKS "
-#else
-#define MODULE_STACKSIZE ""
-#endif
-
-#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM MODULE_STACKSIZE
+#define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY MODULE_REGPARM
#endif /* _ASM_I386_MODULE_H */
--- linux-2.6.15-rc5-mm2-full/arch/i386/kernel/irq.c.old 2005-12-11 15:10:27.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/i386/kernel/irq.c 2005-12-11 15:11:29.000000000 +0100
@@ -33,7 +33,6 @@
}
#endif
-#ifdef CONFIG_4KSTACKS
/*
* per-CPU IRQ handling contexts (thread information and stack)
*/
@@ -44,7 +43,6 @@
static union irq_ctx *hardirq_ctx[NR_CPUS];
static union irq_ctx *softirq_ctx[NR_CPUS];
-#endif
/*
* do_IRQ handles all normal device IRQ's (the special
@@ -55,10 +53,8 @@
{
/* high bits used in ret_from_ code */
int irq = regs->orig_eax & 0xff;
-#ifdef CONFIG_4KSTACKS
union irq_ctx *curctx, *irqctx;
u32 *isp;
-#endif
irq_enter();
#ifdef CONFIG_DEBUG_STACKOVERFLOW
@@ -76,8 +72,6 @@
}
#endif
-#ifdef CONFIG_4KSTACKS
-
curctx = (union irq_ctx *) current_thread_info();
irqctx = hardirq_ctx[smp_processor_id()];
@@ -104,7 +98,6 @@
: "memory", "cc", "ecx"
);
} else
-#endif
__do_IRQ(irq, regs);
irq_exit();
@@ -114,8 +107,6 @@
return 1;
}
-#ifdef CONFIG_4KSTACKS
-
/*
* These should really be __section__(".bss.page_aligned") as well, but
* gcc's 3.0 and earlier don't handle that correctly.
@@ -200,7 +191,6 @@
}
EXPORT_SYMBOL(do_softirq);
-#endif
/*
* Interrupt statistics:
>It seems most problems with 4k stacks are already resolved at least
>in -mm.
>
>I'd like to see this patch to always use 4k stacks in -mm now for
>finding any remaining problems before submitting this patch for Linus'
>tree.
By chance, I read that windows modules used in ndiswrapper
may require >4k-stacks. Will this become a problem?
Jan Engelhardt
--
Cuma 16 Aralık 2005 00:57 tarihinde şunları yazmıştınız:
> >It seems most problems with 4k stacks are already resolved at least
> >in -mm.
> >
> >I'd like to see this patch to always use 4k stacks in -mm now for
> >finding any remaining problems before submitting this patch for Linus'
> >tree.
>
> By chance, I read that windows modules used in ndiswrapper
> may require >4k-stacks. Will this become a problem?
If 8k stacks get removed, yes. So if you have a chance to choose don't buy a
wifi card which doesn't have a native linux driver.
Regards,
ismail
On Thu, 2005-12-15 at 23:57 +0100, Jan Engelhardt wrote:
> >It seems most problems with 4k stacks are already resolved at least
> >in -mm.
> >
> >I'd like to see this patch to always use 4k stacks in -mm now for
> >finding any remaining problems before submitting this patch for Linus'
> >tree.
>
> By chance, I read that windows modules used in ndiswrapper
> may require >4k-stacks. Will this become a problem?
Please refer to the last 5 flamewars on this issue rather than starting
another one.
Lee
On Iau, 2005-12-15 at 23:57 +0100, Jan Engelhardt wrote:
> By chance, I read that windows modules used in ndiswrapper
> may require >4k-stacks. Will this become a problem?
For ndiswrapper to deal with internally. If you see the previous
'discussions' you'll see that is needed anyway as NT stacks are over 8K
Ismail Donmez wrote:
>Cuma 16 Aralık 2005 00:57 tarihinde şunları yazmıştınız:
>
>
>>>It seems most problems with 4k stacks are already resolved at least
>>>in -mm.
>>>
>>>I'd like to see this patch to always use 4k stacks in -mm now for
>>>finding any remaining problems before submitting this patch for Linus'
>>>tree.
>>>
>>>
>>By chance, I read that windows modules used in ndiswrapper
>>may require >4k-stacks. Will this become a problem?
>>
>>
>
>If 8k stacks get removed, yes. So if you have a chance to choose don't buy a
>wifi card which doesn't have a native linux driver.
>
>
>
If the learned folks here think that "ndiswrapper" is some user space
program that people can live without than at least
3 people in my house are doomed. We like to use linux but do not have
luxury that Ismail enjoys. At least windows
does not make such decisions on my behalf. Sigh.
~Puneet
Hi,
On 12/16/05, Puneet Vyas <[email protected]> wrote:
> If the learned folks here think that "ndiswrapper" is some user space
> program that people can live without than at least
> 3 people in my house are doomed. We like to use linux but do not have
> luxury that Ismail enjoys. At least windows
> does not make such decisions on my behalf. Sigh.
While I understand that you're frustrated, please direct it towards
your vendor who is unwilling to open up the hardware documentation.
The binary-only drivers you are using are not supported on Linux (you
took them from Windows, remember) and the only way you're ever going
to get reliable wireless support is by reverse engineering or vendor
opening up the specs.
Pekka
Pekka Enberg wrote:
>Hi,
>
>On 12/16/05, Puneet Vyas <[email protected]> wrote:
>
>
>>If the learned folks here think that "ndiswrapper" is some user space
>>program that people can live without than at least
>>
>>
ndiswrapper can be fixed to work in a 4k stack environment,
even if the windows driver in use needs more than 4k. This
requires some work, because ndiswrapper will then have to
manage its own stack instead of simply using the provided
kernel stack. It is up to all people who want ndiswrapper to
actually do this work.
Note that this work ought to be done anyway, as windows
drivers really assumes they can use 12k of stack, which they
cannot do even with the current 8k stack.
>>3 people in my house are doomed. We like to use linux but do not have
>>luxury that Ismail enjoys. At least windows
>>does not make such decisions on my behalf. Sigh.
>>
>>
Windows makes a lot of such decisions - you just never see them
if you come from the windows world. Could I run windows on my
machine with two keyboards, supporting two simultaneous users?
And in 64-bit mode too? Not now.
Could all the people with other non-x86 processors run windows? No.
>
>While I understand that you're frustrated, please direct it towards
>your vendor who is unwilling to open up the hardware documentation.
>The binary-only drivers you are using are not supported on Linux (you
>took them from Windows, remember) and the only way you're ever going
>to get reliable wireless support is by reverse engineering or vendor
>opening up the specs.
>
> Pekka
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
Puneet Vyas wrote:
> If the learned folks here think that "ndiswrapper" is some user space
> program that people can live without than at least
> 3 people in my house are doomed. We like to use linux but do not have
> luxury that Ismail enjoys. At least windows
> does not make such decisions on my behalf. Sigh.
ndiswrapper can be fixed to work in a 4k stack environment,
even if the windows driver in use needs more than 4k. This
requires some work, because ndiswrapper will then have to
manage its own stack instead of simply using the provided
kernel stack. It is up to all people who want ndiswrapper to
actually do this work.
Note that this work ought to be done anyway, as windows
drivers really assumes they can use 12k of stack, which they
cannot do even with the current 8k stack.
Another problem you may get with windows drivers, is licencing issues.
If they want to, they can set the licencing terms so that you
can't legally run the drivers on linux. Currently, it is only a
question of money. Buy a windows licence, an you can use the
windows driver on linux. It may or may not stay that way. Still, getting
what you want on linux will always be only a matter of money, as there
are wifi cards with _linux_ drivers out there. Just buy the right ones
the next time you renew your pc.
Helge Hafting