В Птн, 23/12/2011 в 09:24 -0500, Ryan C. England пишет:
> Thanks again for the assistance.
>
>
> When I ran "make menuconfig" yesterday, the only option I could find
> was CONFIG_4KSTACKS. This is not the option that I'm looking for.
CONFIG_4KSTACKS means using 4Kb for kernel stacks instead of default
8Kb. This option may be useful for intensive multithreading calculations
-- it's reduce "the pressure on the VM subsystem for higher order
allocations".
> Does simply chaning THREAD_ORDER from 1 to 2 increase the stack size?
> Are any further changes requred?
I think -- it's may be sufficient. THREAD_ORDER -- number of memory
pages allocated per thread: 0 - 4k, 1 - 8k, 2 - 16k.
"Kernel hacking" -> "Use 4Kb for kernel stacks instead of
8Kb" (CONFIG_4KSTACKS) in "make menuconfig" must be unselected.
> Thank you
>
> On Fri, Dec 23, 2011 at 1:52 AM, Oleg Sadov <[log in to unmask]>
> wrote:
> 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
>
>
>
>
>
> --
> Ryan C. England
> Corvid Technologies
> office: 704-799-6944 x158
> cell: 980-521-2297
>
|
