Как заставить nouveau упырить мел и не пытаться отгрузить 100500 ФПС при использовании DRI_PRIME?

У меня есть ноут с интел+нвидиа, и я только что узнал что для моих задач nouveau + gallium-nine сильно лучше проприетарного драйвера, но будучи ноутом эта шарманка имеет свойство греться. Поэтому хочется ограничить нагрузку на дискретку старым провереным способом - ограничением ФПС. Уровни pstate хорошо справляются с общим ограничением производительности, но они слишком дискретные, и там на выбор только овощ, печка и жерло вулкана.

Для иксов есть опция в конфиге для vsync'а, но DRI_PRIME на иксы побоку. Как быть?

Захотелось мне странного, и решил потыкать палочкой в wine-nine.

Для него, вестимо, требуется gallium-nine

А у нас есть ажно интеловская интеграшка от ivy bridge, которая без дополнительных телодвижений использует классический i965. А галлиум на ней запилен в ilo (и я даже уверен, что оно когда-то работало в какой-то бубунте), а меса в арче собрана без него.

В общем, стянул я из AURа PKGBUILD гитовой месы и стал её собирать с --with-gallium-drivers=ilo, и оно даже как-то собралось и даже как-то поставилось.

Но есть нъюанс.

(EE) AIGLX error: ilo does not export required DRI extension
(EE) AIGLX: reverting to software rendering

сказал Xorg в ответ на Option «DRI» «ilo»

И хто виноват? И шо делать?

Чего кроме месы и с какими ключами надо собирать, чтобы оно взлетело? В xf86-video-intel намеков на дополнительные телодвижения нет (и вообще, должны ли они быть? ЯННП архитектуру этого вашего галлиума, и как оно соотносится с иксами и классическими дровами). Гуглфу подвело.

2ой день долблюсь головой о стену. За каждым углом коварно поджидают грабли. Решил спросить у умных людей.

Итак, дано. Есть шлюз на Debian Wheezy. У шлюза, кроме всего прочего, есть внешний интерфейс eth2 и 2 внутренних влана eth1.10 и eth1.20.

В eth2 приходит 30 мбит от провайдера. На eth1.10 и eth1.20 100мбит локалки, которые активно общаются друг с другом и ходят в интернет через нат на этом самом шлюзе.

Провайдер регулирует полосу дропом пакетов. Предположительно, из-за этого у пользователей периодически рвутся соединения.

Очевидное решение - попытаться мягко ограничить на шлюзе входящую полосу и надеяться, что это будет работать.

Есть ньюанс. Условно говоря, eth1.10 - для випов и мажоров. eth1.20 - для плебеев. Соответственно, нужно приоретизировать входящий трафик в зависимости от его пункта назначения в локальной сети.

Из ньюанса вытекает, что я не могу шейпить входящий трафик на eth2, потому что qdisc, насколько я понимаю, работает до попадания пакета в PREROUTING, в котором происходит nat. Соответственно, в этот момент я еще не знаю, куда предназначается трафик (плюс, насколько я понял, ingress qdisc умеет только полисить. Методом дропа. Так что смысл теряется).

Из ньюанса так же вытекает, что я не могу шейпить трафик, выходящий из eth1.10 и eth1.20, потому что qdisc локальный для интерфейса, и я не могу сопоставить приоритеты на разных интерфейсах.

Не совсем понимаю, как работает IFB (в том смысле, каким путем трафик этот самый IFB покидает, и где на диаграмме netflow он оказывается), но судя по всему, я мог бы связать eth1.10 и eth1.20 через IFB. Мог бы. Если бы не одно но. На IFB, насколько я понял, нет нетфильтра. И он не видит нетфильтровские метки MARK. Можно только делать u32 match. Но у u32 match нет реверс матча. А поскольку локалки eth1.10 и eth1.20 общаются между собой на всех 100 мегабитах, мне внутренний трафик шейпить совсем не хочется, и нужно исключить из шейпера определенный диапазон адресов.

Куда попадают пакеты, прошедшие через IFB? (например, на этой диаграмме http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg)

Как обрабатывать эти пакеты в iptables? (скажем, гипотетически, если я повешу ifb0 на eth2 ingress qdisc, то какой интерфейс нужно будет использовать для правил iptables, чтобы обрабатывать входящий на eth2 трафик? -i ifb0?)

Как разрулить проблему с 2мя внутренними интерфейсами (или натом)?