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.<div><br></div><div>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.</div>
<div><br></div><div>Thank you<br><br><div class="gmail_quote">On Mon, Dec 12, 2011 at 4:00 AM, Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com">david@fromorbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mon, Dec 12, 2011 at 06:13:11AM +0100, Andi Kleen wrote:<br>
> > It's ~180 bytes, so it's not really that small.<br>
><br>
> Quite small compared to what real code uses. And also fixed<br>
> size.<br>
><br>
> ><br>
> > > is on the new stack. ISTs are not used for interrupts, only for<br>
> > > some special exceptions.<br>
> ><br>
> > IST = ???<br>
><br>
> That's a hardware mechanism on x86-64 to switch stacks<br>
> (Interrupt Stack Table or somesuch)<br>
><br>
> With ISTs it would have been possible to move the the pt_regs too,<br>
> but the software mechanism is somewhat simpler.<br>
><br>
> > at the top of the stack frame? Is the stack unwinder walking back<br>
> > across the interrupt stack to the previous task stack?<br>
><br>
> Yes, the unwinder knows about all the extra stacks (interrupt<br>
> and exception stacks) and crosses them as needed.<br>
><br>
> BTW I suppose it wouldn't be all that hard to add more stacks and<br>
> switch to them too, similar to what the 32bit do_IRQ does.<br>
> Perhaps XFS could just allocate its own stack per thread<br>
> (or maybe only if it detects some specific configuration that<br>
> is known to need much stack)<br>
<br>
</div></div>That's possible, but rather complex, I think.<br>
<div class="im">> It would need to be per thread if you could sleep inside them.<br>
<br>
</div>Yes, we'd need to sleep, do IO, possibly operate within a<br>
transaction context, etc, and a workqueue handles all these cases<br>
without having to do anything special. Splitting the stack at a<br>
logical point is probably better, such as this patch:<br>
<br>
<a href="http://oss.sgi.com/archives/xfs/2011-07/msg00443.html" target="_blank">http://oss.sgi.com/archives/xfs/2011-07/msg00443.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Dave.<br>
--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Ryan C. England</div><div><a href="http://www.corvidtec.com/" target="_blank">Corvid Technologies</a></div>office: 704-799-6944 x158<br>cell: 980-521-2297<br>
</div>