Date: Thu, 2 Oct 2014 17:33:45 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Larry Baird <lab@gta.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Ryan Stone <rysto32@gmail.com>, Dimitry Andric <dim@FreeBSD.org>, Bryan Drewery <bdrewery@FreeBSD.org> Subject: Re: Kernel/Compiler bug Message-ID: <20141002143345.GY26076@kib.kiev.ua> In-Reply-To: <20141002140232.GA52387@gta.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141002143345.GY26076>