В Птн, 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 <[email protected]> > 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 > > <[email protected]> wrote: > > Does anyone know how this may be accomplished? > > > > > > Thank you > > > > > > On Thu, Dec 15, 2011 at 11:32 AM, Ryan C. England > > <[email protected]> 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 <[email protected]> > > Date: Mon, Dec 12, 2011 at 5:47 PM > > Subject: Re: XFS causing stack overflow > > To: "Ryan C. England" > <[email protected]> > > Cc: Andi Kleen <[email protected]>, > Christoph > > Hellwig <[email protected]>, > [email protected], > > [email protected] > > > > > > 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 > > <[email protected]> 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 > > [email protected] > > > > > > > > > > > > -- > > 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 >
