Энергозбережения памяти

Современная DRAM требует чтобы с определенной периодичностью на ней вызывался режим регенерации. Каждый N период времени устанавливалась выборка строки и запись этой обратно для обновления значений - так как из-за токов утечки постепенно значение сбрасывается.

Идея:

1. Для случая когда несколько планок памяти - не используемые планки памяти сбрасываются на минимальную тактовую частоту и отключаются любые обновления и обращения к этой планке. Когда понадобиться эта планка она заново инициализируется на нормальный режим. Думаю это не возможно, так как все планки контролером памяти обрабатываются совместно и использовать разные настройки памяти не возможно, так всегда используются максимальный из доступных на всех планках режим. Можно конечно для энергосбережения понижать настройки у всех планок - но думаю без сброса памяти - это сделать без потери содержимого памяти сейчас нельзя - или я просто не слушал про такой подход к энергосбережению. Хотя возможно можно успеть сменить настройки памяти до следующего цикла регенерации.
2. Более реалистичный режим - добавить дополнительный бит на каждую строку в чипе памяти - при установленном этом бите все запросы на получение возвращают нули регенерация игнорируется. По умолчанию после инициализации эти биты установлены. при первой попытке что нибудь записать в эту сроку эти биты сбрасываются. Только нужно какой-то дополнительный интерфейс для установки  этого бита во время работы.
3. и самый реалистичный метод - сбрасывать все неиспользуемые области памяти - по идее на сброшенный строках  во время регенерации тратится минимум энергии.

Но похоже что-то подобное уже реализовано Samsungом, когда обновляется только реально используемая память.

P.S. links:

1. Partial Array Self-refresh in Linux - читать здесь
2. POWER EVALUATION OF A HANDHELD COMPUTER
3. Analysis of the PASR Standard and its usability in Handheld Operating Systems such as Linux

Мысли o AMD Liano

Нашел достаточно интересное описание новой платформы AMD Liano. И появилось пара интересных мыслей:

Интерсно как измениться энорнопотребление, если убрать полностью поддержку 16/32 режимов - оставить только поддержку 64 битных инструкции, также убрать полностью сопроцессор и все SSE/3dNow инстркции и выполнять их через прерывание, как для случая без сопроцесора. И так как на ядре уже есть видеокарта с 400 процессорами с возможностью использования как вещественною/целочисленую числодробилку на нем и выполнять эти инструкциии.

Тогда процесор будет стартовать в режиме 64 бит, загружать код поддерки остальных режимов и эмулировать их. После нормальной загрузки использовать только OpenCL.

Хотя может сейчас уже процесор в микрокоде не сожержит поддержки старых режимов, а только эмулирует их? При этом 64 режим в микрокоде очень близок к переводу один в один? Но всеже зачем нам SSE, если есть 400 дробилок уже есть - но правда данный будут передоваться через PCIExpress - но доступ к памяти и кешу будет достаточно быстр - они всетаки уже общие.

Частично это навеяно другой платформой: Bulldozer где на ядра 1 блок вещественной арифметики, PowerPC где не поддерживаемые инструкции эмулируются.

P.S. И маленькое уточнение - нашел еще подробности этой архитектуры.

Управление питанием видеокарты

Есть простенький способ управлять потреблением видеокарты:

echo profile > /sys/class/drm/card0/device/power_method

echo  {auto,high,low,mid} > /sys/class/drm/card0/device/power_profile

где {auto,high,low,mid} - нужный нам режим.

P.S. Маленькое обновление.

Google Chrome - 2

Обнаружил пару интересный настроек: about:flags и включил пару интересных флагов:

• GPU Accelerated Compositing
• GPU Accelerated Canvas 2D

Маленькое изменение результатов с этими флагами:

• chrome - CPU1 - 60% , CPU2 - 80%, GPU - 11%, FPS - 32-36
• chrome, linux, WebGL on - CPU1 - 30% , CPU2 - 90%, GPU - ?, FPS - 17-19
• chrome, linux, WebGL off - CPU1 - 50% , CPU2 - 80%, GPU - ?, FPS - 1

Google Chrome

Обнаружилось что WebGL в chrome под linux отключен, про отключение ff слышал, про хром както пропустил. Причем отключен он только для radeon и intel.

Проверить это очень легко вводим about:gpu и если видим что-то подобное: ATI cards in Linux are crash-prone. То усилием воли закрываем все вкладки и перезапускаем с 'google-chrome --ignore-gpu-blacklist' и радуемся новым впечатлениям :-)

И немного тестов рыбками из демок под ie:

• ie9 - CPU1 - 8% , CPU2 - 10%, GPU - 40%, FPS - 60
• chrome - CPU1 - 40% , CPU2 - 90%, GPU - 10%, FPS - 35
• chrome, linux, WebGL on - CPU1 - 30% , CPU2 - 90%, GPU - ?, FPS - 15
• chrome, linux, WebGL off - CPU1 - 50% , CPU2 - 80%, GPU - ?, FPS - 16
• ff 4.0, linux, WebGL off - CPU1 - 75% , CPU2 - 75%, GPU - ?, FPS - 60

В тестах использовал 20 рыбок. Нагрузку на GPU измерял в AMD System Monitor, которая есть только под Windows. Тест представляет собой движение спрайта по канвасу(в ресурсах есть картинка c полной анимацией движения рыбки).

Еще пара мелких оптимизаций

Использование более удобный для кеширование url(пример для Apache):

• создаем папочку с файлом .htaccess:
  RewriteEngine On
  RewriteRule ^/?(.*)/(.*)$ /$1?$2 [L]
  

• И запрашиваем все файлы из нее по url вида имя папки/нужный ресурс/старый путь относительно корня/параметры вызова - в результате получим, что то подобное /img/avatar.sh?user=1 => /stat/img/avatar.sh/user=1.

И возможность заставить всех ходить через https без перенаправления - стоит пользователю один раз зайти через https - и в течении указаного в заголовке Strict-Transport-Security времени браузер обязан сам заменять все запросы к http на https без запроса к серверу. То есть человек один раз делает запрос на http - мы его перенаправляем на https, и уже на запрос по https мы ему указываем что в течении определенного времени делать запросы только на https.

Кувалда и душа

Брел сегодня по улице - вижу двое ремонтируют забор, что они все таки делают? Если у нас с одинаковым успехом и главное видом (очень страшная гримаса), могут использовать кувалду для настройки и ремонта микроэлектронной техники, так и для добычи из оной ценных блестящих побрякушек.