ограничить cpu usage

Приоритет процесса по CPU можно задать утилитой nice.
Но мне кажется что ситуации вроде описанной планировщик должен разруливать и без приоритетов.

Про найс знаю. пробовал ставить всем нужным процессам -20 (максимум). Эффекта нет. Кушает проц не конкретный процесс, а ядро. При упаковке/распаковке l2tp и в iptables. Видимо шедулинг построен так, что в этом случае юзер процессам вообще перестает выделяться cpu. Возможно, процессорное время забирают прерывания. Только ядро обработает очередную порцию данных - тут же опять прерывание от сетевой карточки и опять обработка.

Есть идея запретить использование kernel l2tp. Раньше xl2tpd его не поддерживал, потом поддержку добавили. Буду искать как ее обратно отключить. Если в userland оно будет жрать процессор - это не страшно, всегда можно приоритетами поправить

Cpulimit

Попробовал userland вариант xl2tpd.

/etc/xl2tpd/xl2tpd.conf :

[global] force userspace = yes

Скорость в 20-25 мбит упала до 6, cpu распределился так : 25% userland процесс xl2tpd, 75 - ядро. По крайней мере не вешаются остальные процессы.

Решил все-таки отказаться от такого варианта. Включил обратно kernel и поставил ограничение скорости l2tp соединения через wondershaper.

Еще на этой платформе от перегруза в ядре роутер ребутался. Виновником оказался watchdog timer. Его пришлось отключить при сборке ядра. Теперь не ребутается, но если вдруг что-то зависнет - придется вручную выключать и включать.

Можно еще попробовать заменить планировщик процессов в ядре. Например наложив патч BFS. Но может конечно и не собраться, хотя истории успеха есть, даже скорость через iperf увеличивалась. Еще желательно использовать последню версию из trunk, бывает что присылают патчи здорово увеличивающие производительность.

Ну а так кроме как через wondershaper ничего и не ограничишь, если kernel space.

Нашел в kernel_menuconfig такую опцию

Preemption model No forced preemption (стоит по умолчанию) Voluntary kernel preemption Preemptible kernel (low-latency desktop)

The preemptive kernel is such that kernel code itself can be preempted. That sounds redundant but it's worth noting that we mean the kernel is preemptible, not that «the kernel supports preemption». Forced/involuntary preemption means that even while servicing a system call, an interrupt for a high priority user process can «force» the kernel to context switch so that it will now run (technically it's not really a context switch, but it has the same effect). This decreases the latency of a user process «seeing» a change in hardware state.

К сожалению, уже отдал роутер, проверить не могу. А так бы поставил preemptible kernel