Re: x86: 4kstacks default - Kernel

This is a discussion on Re: x86: 4kstacks default - Kernel ; > The code in the kernel that gets the fewest coverage at all are our > error paths, and some vendor might try 4k stacks, validate it works in > all use cases - and then it will blow up ...

+ Reply to Thread
Page 2 of 8 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 154

Thread: Re: x86: 4kstacks default

  1. Re: x86: 4kstacks default

    > The code in the kernel that gets the fewest coverage at all are our
    > error paths, and some vendor might try 4k stacks, validate it works in
    > all use cases - and then it will blow up in some error condition he
    > didn't test.


    Which you won't fix by changing the x86 defaults. More of a problem in
    embedded small devices is the 8K allocation failing in the first place -
    plus 4K x 80 processes == lots.

    > And from a QA point of view the only way of getting 4k thoroughly tested
    > by users, and well also tested in -rc kernels for catching regressions
    > before they get into stable kernels, is if we get 4k stacks enabled
    > unconditionally on i386.


    At which point some distros will simply patch it back no doubt.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: x86: 4kstacks default

    Eric Sandeen writes:

    > Adrian Bunk wrote:
    >> On Sat, Apr 19, 2008 at 04:35:31PM +0200, Oliver Pinter wrote:
    >>> ...
    >>> with the older kernel is typical: xfs+nfs+4k stack(+lvm)

    >>
    >> Does anyone still experience problems with 2.6.25?

    >
    > There are always problems. You can always come up with something that
    > will crash in 4k, IMHO.


    But what are a few crashes compared against the ability to run 50000
    kernel threads on a 32bit machine? Something has to give in the aim
    for useless checkbox numbers after all.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 12:02:50PM +0100, Alan Cox wrote:
    > > The code in the kernel that gets the fewest coverage at all are our
    > > error paths, and some vendor might try 4k stacks, validate it works in
    > > all use cases - and then it will blow up in some error condition he
    > > didn't test.

    >
    > Which you won't fix by changing the x86 defaults.


    Stuff like nfsd, xfs and raid is covered by the x86 defaults.

    It's not a 100% coverage, but quite much.

    > More of a problem in
    > embedded small devices is the 8K allocation failing in the first place -
    > plus 4K x 80 processes == lots.
    >
    > > And from a QA point of view the only way of getting 4k thoroughly tested
    > > by users, and well also tested in -rc kernels for catching regressions
    > > before they get into stable kernels, is if we get 4k stacks enabled
    > > unconditionally on i386.

    >
    > At which point some distros will simply patch it back no doubt.


    Red Hat seems to get usable kernels with 4k for some years?

    If we get whatever is still missing for 4k working once and then the
    coverage of all i386 -rc testers for noticing new issues immediately
    there should be no stability reason for distros to patch it back in.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: x86: 4kstacks default

    On Sun, 20 Apr 2008 14:54:55 +0300
    Adrian Bunk wrote:

    > Red Hat seems to get usable kernels with 4k for some years?


    Yes and I think it is the right setting.

    > If we get whatever is still missing for 4k working once and then the
    > coverage of all i386 -rc testers for noticing new issues immediately
    > there should be no stability reason for distros to patch it back in.


    You don't get to dictate to people however.

    Alan
    --
    "If we become a great evil avaricious hegemony, I wanna cool uniform"
    -- robk
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 12:37:31PM +0100, Alan Cox wrote:
    > On Sun, 20 Apr 2008 14:54:55 +0300
    > Adrian Bunk wrote:
    >
    > > Red Hat seems to get usable kernels with 4k for some years?

    >
    > Yes and I think it is the right setting.
    >
    > > If we get whatever is still missing for 4k working once and then the
    > > coverage of all i386 -rc testers for noticing new issues immediately
    > > there should be no stability reason for distros to patch it back in.

    >
    > You don't get to dictate to people however.


    Everyone is free to patch whatever stacksize he wants into his kernel.

    But the more users will get 4k stacks the more testing we have, and the
    better both existing and new bugs get shaken out.

    And if there were only 4k stacks in the vanilla kernel, and therefore
    all people on i386 testing -rc kernels would get it, that would give a
    better chance of finding stack regressions before they get into a
    stable kernel.

    If a distribution or user then wants to increase it that's his choice
    (and easy to do), but nothing the upstream kernel has to offer.

    > Alan


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: x86: 4kstacks default

    Adrian Bunk writes:
    >
    > 6k is known to work, and there aren't many problems known with 4k.
    >
    > And from a QA point of view the only way of getting 4k thoroughly tested


    But you have to first ask why do you want 4k tested? Does it serve
    any useful purpose in itself? I don't think so. Or you're saying
    it's important to support 50k kernel threads on 32bit kernels?

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 02:27:14PM +0200, Andi Kleen wrote:
    > Adrian Bunk writes:
    > >
    > > 6k is known to work, and there aren't many problems known with 4k.
    > >
    > > And from a QA point of view the only way of getting 4k thoroughly tested

    >
    > But you have to first ask why do you want 4k tested? Does it serve
    > any useful purpose in itself? I don't think so. Or you're saying
    > it's important to support 50k kernel threads on 32bit kernels?


    Small embedded systems like the space savings.

    > -Andi


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: x86: 4kstacks default

    Adrian Bunk writes:
    >
    > Red Hat seems to get usable kernels with 4k for some years?


    One way they do that is by marking significant parts of the kernel
    unsupported. I don't think that's an option for mainline.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: x86: 4kstacks default

    Eric Sandeen writes:
    >
    > CONFIG_DEBUG_STACKOVERFLOW isn't ery useful because the warning printk
    > it generates uses the remaining amount of stack, and tips the box.


    That could be easily fixed by executing the printk on the interrupt
    stack on i386. Currently it is before the stack switch which is wrong
    agreed. On x86-64 it should already execute on the interrupt stack. Or
    perhaps it would be better to just move the stack switch on i386 into
    entry.S too similar to 64bit.

    That wouldn't help without interrupt stacks of course, but these
    should be always on anyways even with 8k stacks.

    Experimental patch appended to do this.

    -Andi

    ---

    i386: Execute stack overflow warning on interrupt stack

    Previously it would run on the process stack, which risks overflow
    an already low stack. Instead execute it on the interrupt stack.

    Based on an observation by Eric Sandeen.

    Signed-off-by: Andi Kleen

    Index: linux/arch/x86/kernel/irq_32.c
    ================================================== =================
    --- linux.orig/arch/x86/kernel/irq_32.c
    +++ linux/arch/x86/kernel/irq_32.c
    @@ -61,6 +61,26 @@ static union irq_ctx *hardirq_ctx[NR_CPU
    static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
    #endif

    +static void stack_overflow(void)
    +{
    + printk("low stack detected by irq handler\n");
    + dump_stack();
    +}
    +
    +static inline void call_on_stack2(void *func, unsigned long stack,
    + unsigned long arg1, unsigned long arg2)
    +{
    + unsigned long bx;
    + asm volatile(
    + " xchgl %%ebx,%%esp \n"
    + " call *%%edi \n"
    + " movl %%ebx,%%esp \n"
    + : "=a" (arg1), "=d" (arg2), "=b" (bx)
    + : "0" (arg1), "1" (arg2), "2" (stack),
    + "D" (func)
    + : "memory", "cc");
    +}
    +
    /*
    * do_IRQ handles all normal device IRQ's (the special
    * SMP cross-CPU interrupts have their own specific
    @@ -76,6 +96,7 @@ unsigned int do_IRQ(struct pt_regs *regs
    union irq_ctx *curctx, *irqctx;
    u32 *isp;
    #endif
    + int overflow = 0;

    if (unlikely((unsigned)irq >= NR_IRQS)) {
    printk(KERN_EMERG "%s: cannot handle IRQ %d\n",
    @@ -92,11 +113,8 @@ unsigned int do_IRQ(struct pt_regs *regs

    __asm__ __volatile__("andl %%esp,%0" :
    "=r" (sp) : "0" (THREAD_SIZE - 1));
    - if (unlikely(sp < (sizeof(struct thread_info) + STACK_WARN))) {
    - printk("do_IRQ: stack overflow: %ld\n",
    - sp - sizeof(struct thread_info));
    - dump_stack();
    - }
    + if (unlikely(sp < (sizeof(struct thread_info) + STACK_WARN)))
    + overflow = 1;
    }
    #endif

    @@ -112,8 +130,6 @@ unsigned int do_IRQ(struct pt_regs *regs
    * current stack (which is the irq stack already after all)
    */
    if (curctx != irqctx) {
    - int arg1, arg2, bx;
    -
    /* build the stack frame on the IRQ stack */
    isp = (u32*) ((char*)irqctx + sizeof(*irqctx));
    irqctx->tinfo.task = curctx->tinfo.task;
    @@ -127,18 +143,20 @@ unsigned int do_IRQ(struct pt_regs *regs
    (irqctx->tinfo.preempt_count & ~SOFTIRQ_MASK) |
    (curctx->tinfo.preempt_count & SOFTIRQ_MASK);

    - asm volatile(
    - " xchgl %%ebx,%%esp \n"
    - " call *%%edi \n"
    - " movl %%ebx,%%esp \n"
    - : "=a" (arg1), "=d" (arg2), "=b" (bx)
    - : "0" (irq), "1" (desc), "2" (isp),
    - "D" (desc->handle_irq)
    - : "memory", "cc"
    - );
    + /* Execute warning on interrupt stack */
    + if (unlikely(overflow))
    + call_on_stack2(stack_overflow, isp, 0, 0);
    +
    + call_on_stack2(desc->handle_irq, isp, irq, desc);
    +
    } else
    #endif
    + {
    + /* AK: Slightly bogus here */
    + if (overflow)
    + stack_overflow();
    desc->handle_irq(irq, desc);
    + }

    irq_exit();
    set_irq_regs(old_regs);
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 02:27:14PM +0200, Andi Kleen wrote:
    > Adrian Bunk writes:
    > >
    > > 6k is known to work, and there aren't many problems known with 4k.
    > >
    > > And from a QA point of view the only way of getting 4k thoroughly tested

    >
    > But you have to first ask why do you want 4k tested? Does it serve
    > any useful purpose in itself? I don't think so. Or you're saying
    > it's important to support 50k kernel threads on 32bit kernels?


    Clearly if I have the choice between a kernel which can run 50k threads
    and a kernel which does not crash under me during an I/O error, I choose
    the later! I don't even imagine what purpose 50k kernel threads may serve.
    I certainly can understand that reducing memory footprint is useful, but
    if we want wider testing of 4k stacks, considering they may fail in error
    path in complex I/O environment, it's not likely during -rc kernels that
    we'll detect problems, and if we push them down the throat of users in a
    stable release, of course they will thank us very much for crashing their
    NFS servers in production during peak hours.

    I have nothing against changing the default setting to 4k provided that
    it is easy to get back to the save setting (ie changing a config option,
    or better, a cmdline parameter). I just don't agree with the idea of
    forcing users to swim in the sh*t, it only brings bad reputation to
    Linux.

    What would really help would be to have 8k stacks with the lower page
    causing a fault and print a stack trace upon first access. That way,
    the safe setting would still report us useful information without
    putting users into trouble.

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: x86: 4kstacks default

    Willy Tarreau wrote:

    > Clearly if I have the choice between a kernel which can run 50k threads
    > and a kernel which does not crash under me during an I/O error, I choose
    > the later! I don't even imagine what purpose 50k kernel threads may serve.


    I don't know either but it was quoted to me earlier as the primary
    reason 4k stacks were introduced.

    > I have nothing against changing the default setting to 4k provided that
    > it is easy to get back to the save setting


    So you're saying that only advanced users who understand all their
    CONFIG options should have the safe settings? And everyone else
    the "only explodes once a week" mode?

    For me that is exactly the wrong way around.

    If someone is sure they know what they're doing they can set whatever
    crazy settings they want (given there is a quick way to check
    for the crazy settings in oops reports so that I can ignore those), but
    the default should be always safe and optimized for reliability.

    -Andi

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: x86: 4kstacks default

    Willy Tarreau wrote:
    >
    > What would really help would be to have 8k stacks with the lower page
    > causing a fault and print a stack trace upon first access. That way,
    > the safe setting would still report us useful information without
    > putting users into trouble.

    ...

    That's the best suggestion from this thread, by far!
    Can you produce a patch for 2.6.26 for this?
    Or perhaps someone else here, with the right code familiarity, could?

    Some sort of CONFIG option would likely be wanted to
    either enable/disable this feature, of course.

    Cheers
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: x86: 4kstacks default

    Adrian Bunk wrote:
    >
    > The code in the kernel that gets the fewest coverage at all are our
    > error paths, and some vendor might try 4k stacks, validate it works in
    > all use cases - and then it will blow up in some error condition he
    > didn't test.

    ...

    That's exactly the worry.

    If anyone want's to take a crack at testing some of the more likely
    fail paths there, just introduce a media error onto a SATA disk
    that's buried at the bottom of a stacked RAID1 over RAID0 over LVM,
    with XFS and nfsd on top.

    Or something like that.
    And then experiment with corrupting meta data rather than simply file data.
    How-to introduce a media error? hdparm --make-bad-sector nnnnnn /dev/sdX

    This catches the most likely (IMHO) failure scenarios,
    but still comes nowhere near 100% code coverage.

    Cheers
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 02:47:17PM +0200, Willy Tarreau wrote:
    >...
    > I certainly can understand that reducing memory footprint is useful, but
    > if we want wider testing of 4k stacks, considering they may fail in error
    > path in complex I/O environment, it's not likely during -rc kernels that
    > we'll detect problems, and if we push them down the throat of users in a
    > stable release, of course they will thank us very much for crashing their
    > NFS servers in production during peak hours.


    I've seen many bugs in error paths in the kernel and fixed quite a
    few of them - and stack problems were not a significant part of them.

    There are so many possible bugs (that also occur in practice) that
    singling out stack usage won't gain much.

    > I have nothing against changing the default setting to 4k provided that
    > it is easy to get back to the save setting (ie changing a config option,
    > or better, a cmdline parameter). I just don't agree with the idea of
    > forcing users to swim in the sh*t, it only brings bad reputation to
    > Linux.
    >...


    What actually brings bad reputation is shipping a 4k option that is
    known to break under some circumstances.

    And history has shown that as long as 8k stacks are available on i386
    some problems will not get fixed. 4k stacks are available as an option
    on i386 for more than 4 years, and at about as long we know that there
    are some setups (AFAIK all that might still be present seem to include
    XFS) that are known to not work reliably with 4k stacks.

    If we go after stability and reputation, we have to make a decision
    whether we want to get 4k stacks on 32bit architectures with 4k page
    size unconditionally or not at all. That's the way that gets the maximal
    number of bugs shaken out [1] for all supported configurations before
    they would hit a stable kernel.

    > Willy


    cu
    Adrian

    [1] obviously not all, but that's true for all classes of bugs

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 04:30:07PM +0300, Adrian Bunk wrote:
    > Such a "crazy setting" shouldn't be offered to users at all.
    >
    > We should either aim at 4k stacks unconditionally for all 32bit
    > architectures with 4k page size or don't allow any architecture
    > to offer 4k stacks.


    I agree you make a valid point here. Then wouldn't it be easier to
    simply remove 4k and agree it was a wet dream ?

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 03:06:23PM +0200, Andi Kleen wrote:
    > Willy Tarreau wrote:
    >...
    > > I have nothing against changing the default setting to 4k provided that
    > > it is easy to get back to the save setting

    >
    > So you're saying that only advanced users who understand all their
    > CONFIG options should have the safe settings? And everyone else
    > the "only explodes once a week" mode?
    >
    > For me that is exactly the wrong way around.
    >
    > If someone is sure they know what they're doing they can set whatever
    > crazy settings they want (given there is a quick way to check
    > for the crazy settings in oops reports so that I can ignore those), but
    > the default should be always safe and optimized for reliability.


    That means we'll have nearly zero testing of the "crazy setting" and
    when someone tries it he'll have a high probability of running into some
    problems.

    Such a "crazy setting" shouldn't be offered to users at all.

    We should either aim at 4k stacks unconditionally for all 32bit
    architectures with 4k page size or don't allow any architecture
    to offer 4k stacks.

    > -Andi


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 09:27:32AM -0400, Mark Lord wrote:
    > Willy Tarreau wrote:
    > >
    > >What would really help would be to have 8k stacks with the lower page
    > >causing a fault and print a stack trace upon first access. That way,
    > >the safe setting would still report us useful information without
    > >putting users into trouble.

    > ..
    >
    > That's the best suggestion from this thread, by far!
    > Can you produce a patch for 2.6.26 for this?


    Unfortunately, I can't. I wouldn't know where to start from.

    > Or perhaps someone else here, with the right code familiarity, could?


    I hope so.

    > Some sort of CONFIG option would likely be wanted to
    > either enable/disable this feature, of course.


    If we want to migrate to 4k sooner or later, this behaviour would not
    need a config option, maybe just a /proc or /sys tunable to disable
    the warning. Config would be either (4k + risk of crash) or (8k + warning).

    The *real* issue is to decide whether we need/want 4k or not, because
    I think we're still discussing the subject for no reason, as usual...

    Willy

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: x86: 4kstacks default

    On Sun, Apr 20, 2008 at 03:34:41PM +0200, Willy Tarreau wrote:
    > On Sun, Apr 20, 2008 at 04:30:07PM +0300, Adrian Bunk wrote:
    > > Such a "crazy setting" shouldn't be offered to users at all.
    > >
    > > We should either aim at 4k stacks unconditionally for all 32bit
    > > architectures with 4k page size or don't allow any architecture
    > > to offer 4k stacks.

    >
    > I agree you make a valid point here. Then wouldn't it be easier to
    > simply remove 4k and agree it was a wet dream ?


    If the sh maintainer and the m68knommu maintainer (and perhaps
    MontaVista) agree that it was a wet dream.

    > Willy


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: x86: 4kstacks default

    Mark Lord wrote:
    > Willy Tarreau wrote:
    >> What would really help would be to have 8k stacks with the lower page
    >> causing a fault and print a stack trace upon first access. That way,
    >> the safe setting would still report us useful information without
    >> putting users into trouble.

    > ..
    >
    > That's the best suggestion from this thread, by far!
    > Can you produce a patch for 2.6.26 for this?
    > Or perhaps someone else here, with the right code familiarity, could?
    >
    > Some sort of CONFIG option would likely be wanted to
    > either enable/disable this feature, of course.


    Changing the default warning threshold is easy, it's just a #define.
    Although setting it too low would spam syslogs on some setups.

    When I was trying to cram stuff into 4k in the past, I had a patch which
    added a sysctl to dynamically change the warning threshold, and
    optionally BUG() when I hit it for crash analysis. It was good for
    debugging, at least. If something along those lines is desired, I could
    resurrect it.

    -Eric
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: x86: 4kstacks default

    Adrian Bunk wrote:

    > But the more users will get 4k stacks the more testing we have, and the
    > better both existing and new bugs get shaken out.
    >
    > And if there were only 4k stacks in the vanilla kernel, and therefore
    > all people on i386 testing -rc kernels would get it, that would give a
    > better chance of finding stack regressions before they get into a
    > stable kernel.


    Heck, maybe you should make it 2k by default in all -rc kernels; that
    way when people run -final with the 4k it'll be 100% bulletproof, right?
    'cause all those piggy drivers that blow a 2k stack will finally have
    to get fixed? Or leave it at 2k and find a way to share pages for
    stacks, think how much memory you could save and how many java threads
    you could run!

    4K just happens to be the page size; other than that it's really just
    some random/magic number picked, and now dictated that if you (and
    everyting around you) doesn't fit, you're broken.

    That bugs me.

    -Eric

    (yes, I know there are advantages to only allocating a single page for a
    new thread, but from an "all callchains after that must fit in that
    space" perspective, it's just a randomly picked number)
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 8 FirstFirst 1 2 3 4 ... LastLast