Try to change line
#define THREAD_ORDER 1
to
#define THREAD_ORDER 2
in page_32_types.h or/and page_64_types.h at arch/x86/include/asm/
В Чтв, 22/12/2011 в 12:05 -0500, Ryan C. England пишет:
> Anyone?
>
> On Mon, Dec 19, 2011 at 9:15 AM, Ryan C. England
> <[log in to unmask]> wrote:
> Does anyone know how this may be accomplished?
>
>
> Thank you
>
>
> On Thu, Dec 15, 2011 at 11:32 AM, Ryan C. England
> <[log in to unmask]> wrote:
> Denice,
>
>
> I have spoken with a couple of the guys on the xfs
> mailing list. The quick fix would seem to be
> recompiling the kernel to support a 16K kernel stack.
>
>
> I've spent a few hours researching and have been
> unable to locate anything relative to the 2.6.32
> kernel. It's not easy finding anything regarding a
> patch, or recompiling the kernel to support this
> feature, let along finding anything relative to these
> operations for 2.6.32. Any suggestions?
>
>
> Thank you
>
> ---------- Forwarded message ----------
> From: Dave Chinner <[log in to unmask]>
> Date: Mon, Dec 12, 2011 at 5:47 PM
> Subject: Re: XFS causing stack overflow
> To: "Ryan C. England" <[log in to unmask]>
> Cc: Andi Kleen <[log in to unmask]>, Christoph
> Hellwig <[log in to unmask]>, [log in to unmask],
> [log in to unmask]
>
>
> On Mon, Dec 12, 2011 at 08:43:57AM -0500, Ryan C.
> England wrote:
> > On Mon, Dec 12, 2011 at 4:00 AM, Dave Chinner
> <[log in to unmask]> wrote:
> > > On Mon, Dec 12, 2011 at 06:13:11AM +0100, Andi
> Kleen wrote:
>
> > > > BTW I suppose it wouldn't be all that hard to
> add more stacks and
> > > > switch to them too, similar to what the 32bit
> do_IRQ does.
> > > > Perhaps XFS could just allocate its own stack
> per thread
> > > > (or maybe only if it detects some specific
> configuration that
> > > > is known to need much stack)
> > >
> > > That's possible, but rather complex, I think.
> > > > It would need to be per thread if you could
> sleep inside them.
> > >
> > > Yes, we'd need to sleep, do IO, possibly operate
> within a
> > > transaction context, etc, and a workqueue handles
> all these cases
> > > without having to do anything special. Splitting
> the stack at a
> > > logical point is probably better, such as this
> patch:
> > >
> > >
> http://oss.sgi.com/archives/xfs/2011-07/msg00443.html
> >
>
> > Is it possible to apply this patch to my current
> installation? We use this
> > box in production and the reboots that we're
> experiencing are an
> > inconvenience.
>
>
> Not easily. The problem with a backport is that the
> workqueue
> infrastructure changed around 2.6.36, allowing
> workqueues to act
> like an (almost) infinite pool of worker threads and
> so by using a
> workqueue we can have effectively unlimited numbers of
> concurrent
> allocations in progress at once.
>
> The workqueue implementation in 2.6.32 only allows a
> single work
> instance per workqueue thread, and so even with
> per-CPU worker
> threads, would only allow one allocation at a time per
> CPU. This
> adds additional serialisation within a filesystem,
> between
> filesystem and potentially adds new deadlock
> conditions as well.
>
> So it's not exactly obvious whether it can be
> backported in a sane
> manner or not.
>
> > Is there is a walkthrough on how to apply this
> patch? If not, could your
> > provide the steps necessary to apply successfully?
> I would greatly
> > appreciate it.
>
>
> It would probably need redesigning and re-implementing
> from scratch
> because of the above reasons. It'd then need a lot of
> testing and
> review. As a workaround, you might be better off doing
> what Andi
> first suggested - recompiling your kernel to use 16k
> stacks.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> [log in to unmask]
>
>
>
>
>
> --
> Ryan C. England
> Corvid Technologies
> office: 704-799-6944 x158
> cell: 980-521-2297
>
>
>
>
>
> --
> Ryan C. England
> Corvid Technologies
> office: 704-799-6944 x158
> cell: 980-521-2297
>
>
>
>
>
> --
> Ryan C. England
> Corvid Technologies
> office: 704-799-6944 x158
> cell: 980-521-2297
|
