Ubuntu в ОЗУ

[LepihinMS]

Доустановив некоторое количество софта, я понял, что теперь мне не хватает ОЗУ для полной загрузки в неё ОС.

Потому, считаю такой подход нишевым... может даже... серверным. Надо сильно за 8ГБ ОЗУ.

Плюс, я понял, что несохранение изменений на / - это не всегда хорошо. Чувствуешь себя как на LiveCD.

Итого, надо искать другой путь "осамолёчивания" ОС. Сейчас поставлю виртуальную машинку с Ubuntu и буду глядеть как она реагирует на перемещение тех или иных директорий в tmpfs...

[Kernel ops]

подпишусь

[jamcb]

Сейчас поставлю виртуальную машинку с Ubuntu и буду глядеть как она реагирует на перемещение тех или иных директорий в tmpfs...

Ждём результатов.
Хочу предложить свою теорию загрузки в память.
В дополнение к вышенаписанному мануалу.
Сначала в память грузится только ядро.А для ядра пишется патч, на вызов функции чтения файла. Если файл не найден, вызывается  копирование файла в память с диска, и чтение происходит снова. Можно пойти далее и написать ещё патч, в котором при открытии файла на запись или его создании, ядро создаёт лог изменённых/созданных файлов. Ну а далее этот лог можно скормить rsync`у.

Если вдруг данный топик прочитает человек шарящий в ядре, отпишись пожалуйста, насколько данная теория сложна в реализации. И заранее, спасибо тебе неизвестный кодер

[AnrDaemon]

Смысл грузить рутовый раздел, который не меняется вообще, в ОЗУ? Для экономии ресурса SSD? Так он же не меняется - какой ресурс вы собираетесь экономить? Ресурс чтения?

[jamcb]

Видимо у него диск не разбит на разделы. Всё находится в корне.

[AnrDaemon]

Потрясающе. "Смотрите, как героически мы решаем проблемы, которые сами же себе и создаём!"

[jamcb]

А я на Linuxе только этим и занимаюсь Это Вы уже пережили этап познания системы. А нам надо её ломать, чтоб разобраться как она работает.


Лучше скажите куда копать, чтобы правильно заменить sys_call open? А то пишут, что экспорт листа сисколов был закрыт в ядре 2.6 и дальше. И при попытке компилирования исходников, с включением заголовков ядра выдаёт ошибку

/usr/src/linux-source-3.2.0/linux-source-3.2.0/include/linux/types.h:13:2: предупреждение: #warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders" [-Wcpp]

читал старые статьи по включению модулей в ядро
возможно ли подменить open() через insmod в ядро (на данный момент времени, применительно к текущей версии ядра)?

sys_call table вытаскивается из /proc/kallsyms ?
там правильные данные?

[AnrDaemon]

Никогда не занимался ломанием системы. Даже не знаю, как это делается.

[jamcb]

Такс, модуль в ядро можно не совать. Я думаю, всё можно сделать по-другому. Компилим ядро с уже изменённым вызовом open() и при загрузке указываем другое ядро. Осталось дело за малым подучить C и поменять данный вызов

Код: [Выделить]

long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
961 {
962         struct open_flags op;
963         int lookup = build_open_flags(flags, mode, &op);
964         struct filename *tmp = getname(filename);
965         int fd = PTR_ERR(tmp);
966
967         if (!IS_ERR(tmp)) {
968                 fd = get_unused_fd_flags(flags);
969                 if (fd >= 0) {
970                         struct file *f = do_filp_open(dfd, tmp, &op, lookup);
971                         if (IS_ERR(f)) {
972                                 put_unused_fd(fd);
973                                 fd = PTR_ERR(f);
974                         } else {
975                                 fsnotify_open(f);
976                                 fd_install(fd, f);
977                         }
978                 }
979                 putname(tmp);
980         }
981         return fd;
982 }в файле source/fs/open.c

[kitaets]

Смысл грузить рутовый раздел, который не меняется вообще, в ОЗУ? Для экономии ресурса SSD? Так он же не меняется - какой ресурс вы собираетесь экономить? Ресурс чтения?

Здесь, как мне показалось, не совсем ламеры собрались, чтобы заниматься "экономией ресурса чтения". Рутовый раздел грузится в ОЗУ для повышения производительности системы, там же выше даже тесты есть. Кеширование, к сожалению, даёт не такой хороший эффект.

[AnrDaemon]

Вот мне и интересно, на каких РЕАЛЬНЫХ задачах вы собираетесь ловить это повышение производительности, раз вы не совсем ламеры.

[kitaets]

AnrDaemon,
Понимаю скептицизм.
Если все программы в каком-то конкретном случае резидентны, то такие манипуляции даже не ускорят первичный их запуск (если, конечно, считать, начиная с включения компьютера) - всё равно уйдёт время на их загрузку в ОЗУ. Если же есть множество программ, которые вызываются кратковременно, то они не будут все сидеть в кеше, к сожалению. Правда, глобально прирост производительности вряд ли достигнет даже 5%, скорее это будет повышение комфорта для пользователя. Но лучше такие вещи проверять на практике, результаты часто бывают неожиданными

[LepihinMS]

AnrDaemon, ты чего, товарищ заслуженный пользователь, так разнервничался? Может, тебе, как и мне, просто жалко, что самая быстрая память приходится костылем для SSD/HDD?

Я пришел к выводу, что, в рамках идеи увеличения отзывчивости десктопной системы, переносить какие-либо tmp в tmpfs смысла не имеет.

P.S. Я SSD не экономлю. У меня его нет.

[Freezeman]

А вот мне интересны цифры tiotest:

Код: [Выделить]

--> sudo tiotest -f 25 -d /
Tiotest results for 4 concurrent io threads:
,----------------------------------------------------------------------.
| Item                  | Time     | Rate         | Usr CPU  | Sys CPU |
+-----------------------+----------+--------------+----------+---------+
| Write         100 MBs |    1.8 s |  55.809 MB/s |   4.2 %  |  41.1 % |
| Random Write   16 MBs |    3.1 s |   5.052 MB/s |   0.0 %  |   5.7 % |
| Read          100 MBs |    0.0 s | 7459.347 MB/s | 358.0 %  | 1193.5 % |
| Random Read    16 MBs |    0.0 s | 6901.502 MB/s |   0.0 %  | 1413.4 % |
`----------------------------------------------------------------------'
Почему такая большая скорость чтения? Так и должно быть на HDD?

[thunderamur]

Не знаю, медленнее SSD работает или так же, но после моего старенького ноутбучного HDD видеть запускающийся за полсекунды LibreOffice Writer просто поразительно! Вот с такой скоростью и должен работать ПК в 2013 году!

Ну SSD, конечно, медленнее. Однако, ради интереса попробовал засечь время холодного старта Writer в своей 13.04. Больше полусекунды вышло, но точно не больше секунды! Потом попробовал повторный запуск (т.н. горячий, уже из дискового кэша в ОЗУ) - на глаз разницы не заметил, хотя она есть, я уверен, но уж очень мала.
Пользователь решил продолжить мысль 08 Мая 2013, 20:26:31:

Смысл грузить рутовый раздел, который не меняется вообще, в ОЗУ? Для экономии ресурса SSD? Так он же не меняется - какой ресурс вы собираетесь экономить? Ресурс чтения?

Блин, ну ты же у нас как памятник, почитай 1-й пост. Чел хочет, чтобы "все летало", а не экономить SSD.)))
Пользователь решил продолжить мысль 08 Мая 2013, 20:33:38:

Код: [Выделить]

tiotest -f 25 -d /
Tiotest results for 4 concurrent io threads:
,----------------------------------------------------------------------.
| Item                  | Time     | Rate         | Usr CPU  | Sys CPU |
+-----------------------+----------+--------------+----------+---------+
| Write         100 MBs |    0.3 s | 310.741 MB/s |  19.9 %  | 184.0 % |
| Random Write   16 MBs |    0.1 s | 242.169 MB/s |   0.0 %  | 173.6 % |
| Read          100 MBs |    0.0 s | 10150.223 MB/s | 487.2 %  | 974.4 % |
| Random Read    16 MBs |    0.0 s | 7405.213 MB/s |   0.0 %  | 1516.6 % |
`----------------------------------------------------------------------'