Reducing the need to compile a custom kernel
c.kworr at gmail.com
Mon Feb 13 15:38:19 UTC 2012
Jeremy Chadwick wrote:
> On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote:
>> Jeremy Chadwick wrote:
>>> I want to note here: the pf ALTQ options are a pain in the butt, quite
>>> honestly. I've found in the past that removing the ones you don't use
>>> won't result in a successful build, thus one must include them all. We
>>> do need ALTQ support though, for rate-limiting capability. The NOPCC
>>> option is needed for SMP builds, which makes me wonder what the state of
>>> SMP is in this regard -- meaning, on non-SMP builds, is it still safe
>>> to include ALTQ_NOPCC?
>> It seems like I'm missing something. What is good about using
>> non-SMP kernel?
> Nothing. It's a question of whether or not use of ALTQ_NOPCC causes
> breakage on non-SMP kernels, or if FreeBSD even bothers to support
> non-SMP at this point. "Non-SMP" means "without options SMP".
You got my point. I'm a single core user today but I run SMP-enabled kernel.
> Rephrased: if SMP is the default, and "options SMP" works just fine on
> systems without multiple processors/cores, then the ALTQ_NOPCC option
> should probably be removed.
Yep, works for me. However I had found some cruft about extra processing
power which would be used in expense of correct work. Can this be
something like IPFIREWALL_FORWARD that adds some latency to most cases
providing some use only for chosen ones?
Sphinx of black quartz judge my vow.
More information about the freebsd-stable