Date: Tue, 12 Mar 2013 08:56:37 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org, d@delphij.net Cc: Andriy Gapon <avg@freebsd.org> Subject: Re: FULL_PREEMPTION Message-ID: <201303120856.37443.jhb@freebsd.org> In-Reply-To: <513A26B9.7060305@delphij.net> References: <513A26B9.7060305@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, March 08, 2013 12:58:17 pm Xin Li wrote: > Hi, > > I have seen a few posts from Andriy as as well as the PC-BSD default > that for desktop systems, kern.sched.preempt_thresh=224 would improve > responsiveness. Looking at the code, it seems that this is equivalent > to compiling the kernel with FULL_PREEMPTION. > > The sys/conf/NOTES says, however: > > # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel > # threads. Its sole use is to expose race conditions and other > # bugs during development. Enabling this option will reduce > # performance and increase the frequency of kernel panics by > # design. If you aren't sure that you need it then you don't. > # Relies on the PREEMPTION option. DON'T TURN THIS ON. > > Despite the possibility of exposing race conditions as well as > potentially hurting throughput because of (possibly more) context > switching, is it considered as a goal that we should support it? If > so, should we enable it on -CURRENT? No, it's only ever intended as a debugging aid. I suppose we could consider enabling it in HEAD only just as we do with INVARIANTS, etc. However, when it was added it was never intended to be used for production. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303120856.37443.jhb>