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?
On Fri, Dec 23, 2011 at 10:25 AM, Oleg Sadov <[email protected]> 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 <[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 > > > -- Ryan C. England Corvid Technologies <http://www.corvidtec.com/> office: 704-799-6944 x158 cell: 980-521-2297
