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
