12/01/2012 11:54 -0500, Ryan C. England wrote:
> I was able to compile a test kernel successfully with the options
> given. Is there a way to verify that the size of the kernel stack is
> now 16K?
For ex., by something like this:
grep -i stack /proc/meminfo /proc/vmstat | awk '{s[NR]=$2}END{print s[1]/s[2]}'
More memory manangers info will be logged at /var/log/messages after the
Shift-ScrLock magic keystroke (on text console).
> On Fri, Dec 23, 2011 at 10:25 AM, Oleg Sadov <[log in to unmask]>
> wrote:
> В Птн, 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
> >
>
>
>
>
>
> --
> Ryan C. England
> Corvid Technologies
> office: 704-799-6944 x158
> cell: 980-521-2297
|
