Kernel config
From NuclearCat's homepage
Main goal: each option you choose YES or NO, you must understand what exactly it is doing.
Contents |
Connector
CONFIG_CONNECTOR=y and CONFIG_PROC_EVENTS=y To monitor crashed processes. TODO.
DCA
http://timetobleed.com/enabling-bios-options-on-a-live-server-with-no-rebooting/ TODO: My own research, also to test IO/AT performance
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.
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 ;-).
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
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.
