Kernel config
From NuclearCat's homepage
Main goal: each option you choose YES or NO, you must understand what exactly it is doing.
Contents |
[edit] IRQ Balance (CONFIG_IRQBALANCE)
From: Arjan van de Ven <arjan () infradead ! org> first of all please don't use the in-kernel irqbalancer, use the userspace one from www.irqbalance.org instead...
So recommended by kernel developers to NOT USE kernel option to IRQ_BALANCE.
In the near future, when the NIC vendors wake up[1] because CPU vendors - including big bad Intel - are going to be putting out a large number of hardware threads, you should be able to do more clever things with such a setup. At the moment, just tie it to a single CPU and have your other processes that are related running/bound on the other cores so you can utilize them. OTOH, you say you are only using 30% of the one CPU, so it may not be a big deal to tie your single nic to on cpu.
[1] If you are able to change the NIC in your setup try looking at netiron; email Leonid.Grossman@netiron.com they have a much clever nic than the e1000. It has multiple DMA receive rings which are selectable via a little classifier (example you could have RTP going to CPU0 and rest going to CPU1). The DMA rings could be tied to different interupts/MSI and with some little work could be made to appear like several interfaces.
[edit] CONFIG_RESOURCES_64BIT
Still unclear. Probably for PCI who need to address more than 1G(4G?) of RAM.
Not all 32 bit platforms support more than 4 GiB of memory, so it's of no use to waste memory on 64 bit resources. I'd prefer to have an option to explicitly enable 64 bit resources (and make 32 bit resources non-experimental ;-).
[edit] Enable seccomp to safely compute untrusted bytecode (CONFIG_SECCOMP)
i was profiling the scheduler on x86 and noticed some overhead related
to SECCOMP, and indeed, SECCOMP runs disable_tsc() at _every_
context-switch:
if (unlikely(prev->io_bitmap_ptr || next->io_bitmap_ptr))
handle_io_bitmap(next, tss);
disable_tsc(prev_p, next_p);
return prev_p;
these are a couple of instructions in the hottest scheduler codepath!
x86_64 already removed disable_tsc() from switch_to(), but i think the
right solution is to turn SECCOMP off by default.
besides the runtime overhead, there are a couple of other reasons as
well why this should be done:
- CONFIG_SECCOMP=y adds 836 bytes of bloat to the kernel:
text data bss dec hex filename
4185360 867112 391012 5443484 530f9c vmlinux-noseccomp
4185992 867316 391012 5444320 5312e0 vmlinux-seccomp
[edit] P4 Clock modulation
> > > That's for P4, not X86_64... And since P4 clock modulation does not provide > > > almost any energy savings it was "hidden" under embedded.
> It's sometimes useful in cases where the target CPU doesn't have any better > option (Speedstep/Powernow). The big misconception is that it > somehow saves power & increases battery life. Not so. > All it does is 'not do work so often'. The upside of this is > that in some situations, we generate less heat this way.
For short-term load spikes, yes. If your server has a task which takes up one hour at full time, and the temp reaches 45° C then, but you have nothing else for it to do overnight, then it does might sense to throttle it to 50%, which will mean two hours, but only 40° C.
[edit] MSI/MSI-X interrupts support
4. Why use MSI? As a benefit the simplification of board design, MSI allows board designers to remove out of band interrupt routing. MSI is another step towards a legacy-free environment. Due to increasing pressure on chipset and processor packages to reduce pin count, the need for interrupt pins is expected to diminish over time. Devices, due to pin constraints, may implement messages to increase performance. PCI Express endpoints uses INTx emulation (in-band messages) instead of IRQ pin assertion. Using INTx emulation requires interrupt sharing among devices connected to the same node (PCI bridge) while MSI is unique (non-shared) and does not require BIOS configuration support. As a result, the PCI Express technology requires MSI support for better interrupt performance. Using MSI enables the device functions to support two or more vectors, which can be configure to target different CPU's to increase scalability.
