Date: Thu, 2 Oct 2014 10:51:56 -0700 From: John-Mark Gurney <jmg@funkthat.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Dimitry Andric <dim@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com>, Larry Baird <lab@gta.com>, Bryan Drewery <bdrewery@freebsd.org> Subject: Re: Kernel/Compiler bug Message-ID: <20141002175156.GM43300@funkthat.com> In-Reply-To: <20141002143345.GY26076@kib.kiev.ua> References: <20141001031553.GA14360@gta.com> <CAFMmRNxAYcr8eEY0SJsX3zkRadjT29-mfsGcSTmG_Yx-Hidi6w@mail.gmail.com> <20141001134044.GA57022@gta.com> <FBB9E4C3-55B9-4917-9953-F8BC9AE43619@FreeBSD.org> <542C8C75.30007@FreeBSD.org> <20141002075537.GU26076@kib.kiev.ua> <20141002140232.GA52387@gta.com> <20141002143345.GY26076@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov wrote this message on Thu, Oct 02, 2014 at 17:33 +0300:
> On Thu, Oct 02, 2014 at 10:02:32AM -0400, Larry Baird wrote:
> > > > Is this something that can be bumped in the tree for GENERIC?
> > >
> > > The cost of the increased size for kernel stack is significant, even
> > > on architectures with ample KVA. This must not be done just because
> > > some non-default kernel settings cause stack overflow. If somebody
> > > feels himself qualified enough to tune compiler options, it must
> > > understand the consequences and do other required adjustments,
> > > including kernel stack size tuning.
> > >
> > > FWIW, there was old reason why -O0 did not worked for the kernel.
> > > The cpufunc.h inlines are not provided in non-inline version, and
> > > at least gcc at -O0 level sometimes generated the call to nonexisting
> > > function, leading to linking failure. It is curious that clang always
> > > inlines at -O0, but it is possible, although unlikely, that kernel
> > > source was changed to be immune.
> >
> > Overall I aggree with your comments. The fact is that I have been using
> > -O0 and -O1 on custom kernels for years. It makes using kgdb much more
> > effective. Both optimization levels work for a custom kernel I have for
> > FreeBSD 10.0 but do not work for FreeBSD 10.1. I just tried turning off
> > optimization for a FreeBSD 10.0 release GENERIC kernel. Same issue. My
> > concern is that opimized kernels may be close to the edge as well. Since
> > people have been runing 10.0 for a while without issue, maybe me concern
> > is unfounded. Anybody have any thoughts on how to instrument a kernel
> > build option to check for maximum used stack depth? It would be nice to
> > prove that my concern is unfounded.
>
> The easiest thing to do is to record the stack depth for kernel mode
> on entry into interrupt. Interrupt handlers are usually well written
> and do not consume a lot of stack.
>
> Look at the intr_event_handle(), which is the entry point. The mode can
> be deduced from trapframe passed. The kernel stack for the thread is
> described by td->td_kstack (base, i.e. bottom) and td->td_kstack_pages
> (size), so the top of the stack is at td_kstack + td_kstack_size [*].
> The current stack consumption could be taken from reading %rsp register,
> or you may take the address of any local variable as well.
>
> * - there are pcb and usermode fpu save area at the top of the stack, and
> actual kernel stack top is right below fpu save area. This should not
> be important for your measurements, since you are looking at how close
> the %rsp gets to the bottom.
There once was a script that would print out stack usage for each
function in the kernel... This could help identify functions that
use too much stack... I poked around in tools, but couldn't find it..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141002175156.GM43300>