I/O scheduler (планировщик ввода/вывода)
Вкратце...
Его задача планировщика оптимальным образом обеспечить доступ процесса к запрашиваемому дисковому устройству. Не смотря на всю кажущуюся простоту вопроса, это сложная и противоречивая задача. Работа с дисками относится к очень медленным операциям, имеющая к тому же долгое время поиска нужной информации, а процессов терпеливо ожидающих своей очереди может быть очень много. Поэтому алгоритм I/O scheduler должен с одной стороны уметь уменьшать время поиска информации на диске, ведь частое переключение между задачами приведет к тому, что головка диска будет большую часть времени будет просто переходить на разные позиции. Также I/O scheduler должен уметь выдавать информацию в соответствии с приоритетом и гарантировать получение данных приложению за определенное время и в нужном количестве.
Таким образом, в простой форме: Ядро контролирует доступ к диску, использованием I / O Scheduler.
Deadline
Deadline I/O Scheduler хранит отсортированную очередь, и вводит две дополнительные очереди: FIFO очередь на чтение и FIFO очередь на запись. Записи в каждой из этих очередей отсортированы по времени поступления (фактически, первый вошел -
первый вышел). Каждому запросу в очереди FIFO назначено время окончания. Для очереди запросов чтения - это 500 миллисекунд. Для очереди запросов записи - это пять секунд. При поступлении нового I/O запроса, он вставляется-сортируется в стандартную очередь и помещается в конец соответствующей (на чтение или запись) FIFO очереди.
Как правило, к жесткому диску посылаются запросы ввода/вывода с головы стандартной отсортированной очереди. Это максимизирует общую пропускную способность при минимизации операций поиска и установки головок на диске, так как нормальная очередь сортируется по номеру блока (как и с Linus Elevator). Когда у записи вначале списка одной из дополнительных FIFO очередей истечет назначенное время, I/O scheduler останавливает обработку I/O запросов из стандартной очереди, и начинает обслуживание запросов из этой FIFO очереди. I/O scheduler проверяет и обрабатывает запросы только с головы очереди, где находятся старейшие запросы.
Таким образом, Deadline I/O Scheduler поддерживает эффективную общую пропускную способность без голодания какого-либо одного запроса недопустимо длительное время. Проблема writes-starving-reads сводится к минимуму.
(NOOP)
Самый простой планировщик, обладает минимальными возможностями и выполняет только простые операции объединения и сортировки, но зато и потребляет минимум ресурсов. Он представляет собой очередь FIFO (First In, First Out) то есть он, просто выставляет запросы в очередь в том порядке, в котором они пришли. Предназначен NOOP в основном для работы с не дисковыми устройствами (ОЗУ или флэшдиск) или со пециализированными решениями которые уже имеют свой собственный планировщик I/O. В этом случае его простота имеет преимущество перед остальными алгоритмами.
(CFQ (Completely Fair Queuing))
В CFQ каждому процессу присваивается собственная очередь, и каждой очереди присваивается квант времени (timeslice). Планировщик ввода/вывода по кругу обходит каждую очередь и обслуживает запросы из очереди до тех пор, пока не будет исчерпан лимит времени (timeslice) или не останется запросов в этой очереди. В последнем случае CFQ планировщик будет ждать, по умолчанию 10-мс, нового запроса из очереди. Если ожидание было напрасным, то планировщик переходит к следующей очереди.
В рамках каждой очереди процесса, синхронизированные запросы (как, например, читающие) имеют приоритет над
несинхронизированными запросами. Таким образом, CFQ способствует чтению и предотвращает проблему
writes-starving-reads.
CFQ планировщик хорошо подходит для большинства задач.
в ядрах 2.6.32 и новее можно немного повысить производительность на сервере путём отключения low latency , включенного по умолчанию, которое снижает пиковую производительность, но повышает отзывчивость, нужную только для десктопа.
отключить
(Anticipatory)
Проблема предыдущих планировщиков ввода/вывода вновь вытекает из зависимости: каждый новый запрос на чтение выдается только тогда, когда предыдущий будет возвращен, но к тому времени, когда приложение получает прочитанные данные и посылает следующий запрос на чтение, I/O планировщик уже начал обслуживание других запросов. В этом случае планировщик
ввода/вывода в течении некоторого времени мог бы подождать поступление следующего запроса на чтение. Именно так и работает Anticipatory I/O Scheduler. Он основан на Deadline I/O Scheduler с добавлением механизма ожидания, до шести миллисекунд, следующего чтения. Если 6-ть миллисекунд истекли, но запроса на чтение не поступило, планировщик возвращается к работе, которую выполнял до этого (например, обслуживание стандартной отсортированной очереди).
(BFQ (Budget Fair Queueing))
Планировщик BFQ создан как замена CFQ (и основан на его коде), основная мысль – более честное разделение I/O между процессами.
Работает планировщик отлично – тормоза GUI во время активной работы с диском фоновых процессов (например, загрузки виртуальной машины или обновления дерева portage) просто как рукой сняло.
(SIO)
Цитата(iliz @ 11.01.2012, 15:17) *
SIO - это честный deadline планировщик. на текущий момент (по мнению автора ThunderBolt!) - это лучший планировщик (Однако в FuguMod 1980 его нет, не знаю как в других ядрах).
Более подробно: SIO - это простой планировщик ввода/вывода, в котором разработчики попытались внедрить в Noop систему обнаружения нехватки/истощения ресурсов. Следовательно, длительные IO транзакции будут получать процессорное время только после выполнения более быстрых транзакций (т е приоритет отдается быстрым транзакциям), что позволяет достичь гарантированной гладкости работы. Он не имеет накладных расходов и приоритизации транзакций, т е все транзакции (на чтение или на запись) равны.
OC - overclocking или разгон, повышение частоты процессора / графического ядра свыше штатной для увеличения быстродействия, нагрева и уменьшения времени автономной работы. Неумелое использование ведёт к перегреву и выходу из строя различных компонентов телефона.
UV - undervolting, понижение напряжения процессора / графического ядра для уменьшения нагрева и увеличения времени автономной работы. Неумелое использование ведёт к нестабильности работы телефона, зависаниям и спонтанным перезагрузкам.
Весьма сомнительно, что SGS2 требуется разгон, так как его быстродействие в настоящее время и так избыточное, к тому же он весьма сильно нагревается при активном использовании. Многие (и я в том числе), наоборот, ограничивают максимальную частоту процессора до 1000 или даже до 800 МГц, что совершенно не мешает нормальной работе.
Однако некоторые пользователи не могут спокойно спать, пока не выжмут всё до последнего мегагерца и попугая из своего телефона 
Направление понижения напряжения кажется мне более перспективным, т.к. при определённой аккуратности и везении позволяет значительно снизить потребление батареи (особенно в режиме ожидания, т.к. главным пожирателем батареи всё равно остаётся экран...), а также уменьшить нагрев.
А вот
Некоторые термины
Governor - механизм регулировки частоты процессора телефоном в зависимости от нагрузки.
* Performance - всегда держит максимальную частоту
* Ondemand - при нагрузке быстро поднимает частоту, при пропадании нагрузки медленно её опускает
* Conservative - при нагрузке медленно поднимает частоту, при пропадании нагрузки быстро её опускает
* Powersave - всегда держит минимальную частоту
Легко понять, что приведённые значения отсортированы по возрастанию энергосбережения и по убыванию производительности.
В реальной жизни используются в основном Conservative или Ondemand.
Performance хорош для фаллометрии, а Powersave - для сохранения батареи любой ценой.
Инструменты
Tegrak Overclock Ultimate
Тема на XDA http://forum.xda-developers.com/showthread.php?t=920711
Поскольку данная программа позволяет делать OC/UV вне зависимости от поддержки на уровне ядра, т.к. грузит свой собственный модуль, будем её рассматривать в качестве основного инструмента. Аналогов по гибкости я пока не видел. Однако она несколько неудобна в настройке.
CPU Spy - бесплатная программа для отслеживания истории частоты работы процессора. Не висит в памяти. Также полезна для отслеживания ситуаций, связанных с неоправданно высоким расходом батареи.
Регулировка напряжения и частоты
Буду рассказывать на примере своей прошивки (KF1). Galaxy S ll
Инструкция краткая, если что-то непонятно - лучше лишний раз переспросите!
Установили Tegrak Overclock Ultimate.
Сначала просто выберем диапазон, в котором будет меняться частота процессора.
1. Нажимаем Load overclock module, чтобы загрузить модуль управления частотой и напряжением процессора.
2. Выставим диапазон частот.
- Нажимаем Scaling
- Выбираем Max и Min частоту. У меня стоит 1000 / 200 Mhz.
- Выбираем Governor. У меня стоит Ondemand.
- Нажимаем Apply
3. Нажимаем Set on boot (чтобы изменения применялись после перезагрузки.
Переходим к регулировке напряжения
1. Нажимаем Optimization
2. Имеем список "уровней" процессора: от Level 0 (макс) до Level 4 (мин). Каждому уровню соответствует частота (в скобках приведены значения напряжений по умолчанию):
0 - 1200 (1275, 1100)
1 - 1000 (1175, 1100)
2 - 800 (1075, 1100)
3 - 500 (975, 1000)
4 - 200 (950, 1000)
Также на каждом уровне выбирается напряжение процессора (Core Voltage) и напряжение шины (?) (Internal Voltage).
Чем больше частота, тем больше нужно напряжение, чтобы её поддерживать. Но поскольку производитель заложил некоторый запас напряжения для стабильности, иногда эти напряжения можно уменьшить. При этом телефон будет меньше потреблять энергии и меньше греться. Но если понизить его слишком сильно (т.е. ниже того запаса, который заложен производителем, с учётом особенностей конкретного устройства), процессор станет работать нестабильно, зависать и перегружаться. Для каждого конкретного устройства стабильные значения напряжений свои. Если у кого-то работает на одних напряжениях, это не значит, что и у вас заработает.
Нажав на нужный "уровень", выбираем желаемое напряжение.
ПРОВЕРЯЕМ всё 10 раз!
Если сильно понизить напряжение, то страшного ничего не произойдёт. Ну зависнет, перегрузится... А вот если по ошибке неверно поднять, то можно чего-нибудь и спалить!
Проверив, нажимаем "Apply".
И так для каждого уровня.
После внесения изменений программа в течение 5 минут "тестирует стабильность" в фоне, и если тест не прошёл, откатывает последнее изменение. Весьма полезная фича.
Примеры значений напряжения:
От ув. pro100gamer (довольно консервативные, должны заработать на многих аппаратах):
1200 - 1225, 1050
1000 - 1125, 1050
800 - 1025, 1050
500 - 925, 950
200 - 900, 950
От ув. serj69 (я бы сказал, довольно агрессивные; будьте осторожны):
1200 - 1150, 950
1000 - 1050, 900
800 - 950, 850
500 - 850, 800
200 - 825, 750
Мои настройки:
1200 - 1225, 1050
1000 - 1125, 1050
800 - 1000, 1025
500 - 850, 875
200 - 825, 875
Мои новые настройки, стабильные после недели тестирования:
1200 - 1200, 1000
1000 - 1100, 900
800 - 950, 850
500 - 850, 800
200 - 800, 800
Каждый должен подобрать те настройки, которые заработают именно на его телефоне!
Для тестирования стабильности нужно погонять телефон, позапускать бенчмарки, игры, послушать музыку, посмотреть видео... Если всё будет работать нормально - то можно оставлять. Если нет - откатываться к предыдущим значениям.
AutoKiller
Только с 6 МБ свободной памяти, приложение на переднем плане (то есть активное) будет закрыто
С 12 МБ свободной памяти, видимые приложений будут закрыты
С 16 МБ свободной памяти, вторичные серверы будет закрыты
С 82 МБ свободной памяти, скрытые приложения будут закрыты
С 89 МБ свободной памяти, контент провайдеры будут закрыты
С 97 MБ свободной памяти, пустые приложения будут закрыты
Теперь этот процесс будет полностью автоматизирован самой системой, и это далеко не то же самое, как закрывать приложения сторонними task killer'ами. Задачи будут закрыты изящно и незаметно, в тот момент когда свободной памяти становиться мало. Прелесть autokiller"а в том, что он позволит вам самим настроить параметры для закрытия приложений "на лету". Таким образом, вы можете установить значения в системе, для закрытия пустых приложений в тот момент, когда у вас меньше 60 Мб свободной памяти (для примера). Или же, можно настроить систему более агрессивно, и задать параметры, при которых закрытие пустых (не используемых) приложений будет осуществляться, когда оперативной памяти будет менее 170 МБ (прим. автора). Поскольку эти значения контролируются уже самим Android"ом, autokiller не будет работать в фоновом режиме, как и другие приложения (сторонние task killer'ы). Эти значения, программа применяется при загрузке (путем записи их в /sys/module/lowmemorykiller/parameters/minfree), после чего закрывается. Причина этому, то, что все значения жестко зашиты в систему и при перезагрузке обнуляются, а, следовательно, должны быть изменены после старта системы вновь.
Вы сами можете легко экспериментировать с настройками, но помните, если вы используете "тяжелые" приложения, такие как Sense, то вы должны устанавливать менее высокие значения,либо добавьте его в Whitelist в противном случае система сама начнет убивать эти приложения. Пробуйте, и подбирайте параметры, подходящие именно для вас.
Дополнительно:
FOREGROUND_APP - Приоритетные процессы (на практике - те процессы, которые исполняются сейчас)
VISIBLE_APP - Процессы, которые содержат видимые activity, но не принадлежат к первой группе
SECONDARY_SERVER - Второстепенные процессы (на практике имеют особое значение - так как в эту группу попадают такие сервисы, как лаунчер SenseUI)
HIDDEN_APP - Процессы, которые содержат невидимые activity (в эту группу попадают те процессы, выход из которых осуществлен по клавише Home, или был запущен другой текущий процесс)
CONTENT_PROVIDER - Процесс, который не имеет процессов-потребителей. Если потребители есть, то такой процесс переходит в другую группу.
EMPTY_APP - Процесс, который не имеет запущенных модулей. Первый претендент на высвобождение из памяти.
Чем выше значения, задаваемых параметров, тем жестче политика системы по отношению закрытия приложений.
