LINUX.ORG.RU
← Кто виноват: KDE Plasma или LibAdwaita?
Garuda linux, меню →
 ← 1 2

Холодный запуск с hdd - адовый адд. Есть какие-то способы(кроме переноса на ssd или в память) ускорить запуск?

Составь список файлов, которые клиент Steam открывает при запуске. Напиши скрипт, который вхолостую читает эти файлы, а уже потом запускает клиент Steam, чтобы им уже всё читалось из кеша в ОЗУ. Желательно отсортировать файлы в порядке размещения на диске.

Ещё можно попробовать выделить небольшой раздел для всего связанного со Steam. Это позволит при случайном доступе уменьшить диапазон прыжков считывающей головки.

А вообще сейчас на жёсткие диски при разработке ПО уже мало кто оглядывается, поэтому ситуация с запуском программ с жёстких дисков будет становиться всё хуже и хуже.

i-rinat ★★★★★
()

Есть некий CRIU https://criu.org/. Сам не пользовался, т.к. не было нужды, но, судя по всему, он может тебе подойти. Эта штука позволяет сохранить состояние процесса и потом возобновить его работу из этого сохранения. То есть перед закрытием стима сохраняешь его состояние, а при запуске просто восстанавливаешь.

u5er ★★
()
Ответ на: комментарий от LINUX-ORG-RU

В Linux есть пара дополнительных ioctl, FIBMAP и FIEMAP. С помощью них можно узнать, как именно конкретный файл хранится на диске.

В «Ускорение загрузки с HDD за счет специальной дефрагментации» даже есть скрипт, который с помощью filefrag вычисляет последовательность, в которой нужно читать файлы.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Почитал, и я так понял достаточно дёрнуть FIBMAP причём только один раз на файл, а не рассчитывать из скольких он там блоков состоит. И он скажет номер блока, я так понял физического, ну тоесть отразит наш номер блока на тот что реальный. И если для файлов A B C номера первых их блоков будут 10050050 10050010 10050015 то загружать их надо в порядке B C A чтобы шпиндель винчестера при чтении двигался от края до края равномерно при чтении, а не прыгал.

Накалякал вот

#include <sys/ioctl.h>  /* ioctl  */
#include <stdio.h>      /* printf */
#include <assert.h>     /* assert */
#include <linux/fs.h>   /* FIBMAP */
#include <fcntl.h>      /* open   */
#include <unistd.h>     /* close  */
#include <errno.h>      /* errno  */
#include <stdlib.h>     /* system */
#include <string.h>     /* strcmp */

unsigned long file_start_block(const char * filename)
{
    int file_descrptor = open(filename,O_RDONLY);
    assert(file_descrptor);
    /*--------------------------------------------------
     * FIBMAP принимает номер блока файла и возвращает
     * его соотвецтвующий физический номер блока
     * Файл может состоять из множества блоков.
     * Но мы запрашиваем только физический номер
     * первого блока '0' остальные нас не интересуют.
     --------------------------------------------------*/
    unsigned long file_block=0;/*Первый номер блока*/
    if(ioctl(file_descrptor,FIBMAP,&file_block) == -1)
    {
        fprintf(stderr,"[FILEDON ERROR] IOCTL FIBMAP : ERRNO CODE = %d\n",errno);
        close(file_descrptor);
        return -1;
    }
    close(file_descrptor);
    return file_block;
}

int main(int argc, char *argv[])
{
    if(argc > 1)
    {
        if(strcmp(argv[1],"--setcap") == 0)
        {
            char cmd[512]={0};
            printf("ENTER ROOT PASSWORD\n");
            snprintf(cmd,sizeof(cmd),"su -c \"setcap 'cap_sys_rawio=ep cap_sys_admin=ep' %s\n\"",argv[0]);
            system(cmd);
            return 0;
        }
        printf("%s -> %ld\n",argv[1],file_start_block(argv[1]));
    }
    return 0;
}

dron@gnu:~/Рабочий-стол/filedon$ make
cc main.c -o filedon
dron@gnu:~/Рабочий-стол/filedon$ ./filedon --setcap
ENTER ROOT PASSWORD
Пароль: 
dron@gnu:~/Рабочий-стол/filedon$ tree -L 1
.
├── filedon
├── main.c
└── Makefile

1 directory, 3 files
dron@gnu:~/Рабочий-стол/filedon$ ./filedon filedon 
filedon -> 134101156
dron@gnu:~/Рабочий-стол/filedon$ ./filedon main.c 
main.c -> 70923861
dron@gnu:~/Рабочий-стол/filedon$ ./filedon Makefile 
Makefile -> 165830692
dron@gnu:~/Рабочий-стол/filedon$

Получается если я хочу чуть побыстрее закешировать файлы Makefile,main.c,filedon прогнав их fopen()/fclose() в холостую (ну или прочитать их ещё в холостую) то мне нужно сделать это в порядке

  • main.c
  • filedon
  • Makefile

Я правильно мыслю? Ну то есть как ты там сказал адреса фрагментов первых получили и в порядке от наименьшего к наибольшему сортируем и хаваем ням ням да?

Тестов на большом количестве файлов ещё не проводил. По FIBMAP только крупицы какие то нашёл, но мало. Мол вот он есть и всё.

Но мне кажется я поспешил с выводами, и спать пора…

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от ox55ff

Запроприетаренное и ограниченное по самые гланды поделие. Не, спасибо. В мультиплатфориу я и на пк могу рубиться, а хороших эксклюзивов сони не выдают, уже с периода пс3.

X-Quark
()
Ответ на: комментарий от X-Quark

Запроприетаренное и ограниченное по самые гланды поделие.

Вам шашечки или ехать? Я покупаю консоль, чтобы играть, а не пердолится со свободными прошивками.

хороших эксклюзивов

год войны, горизонт.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

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

X-Quark
()
Ответ на: комментарий от i-rinat

Напиши скрипт, который вхолостую читает эти файлы

Есть такое в арчвики, https://wiki.archlinux.org/title/Ext4#E4rat:

E4rat - это приложение предварительной загрузки, разработанное для файловой системы ext4.
Он отслеживает файлы, открытые во время загрузки, оптимизирует их размещение на разделе, чтобы увеличить время доступа, и предварительно загружает их в самом начале процесса загрузки.

Сам не использовал.

krasnh ★★★★
()
Ответ на: комментарий от X-Quark

кинцо с примитивным геймплеем

Минусы будут? После работы кинцо самое то. Остальное это дрочильни напополам с донатными помойками. Не, ну если ты сам донатный дрочильник, то тогда вопросов не имею.

ox55ff ★★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Тонны проприетарного неаудитабельного кода без сэндбоксов? Да правда.

Игровой, личный, рабочий. Максимум, что можно спрессовать: игровой как виртуалка на личном.

t184256 ★★★★★
()
Последнее исправление: t184256 (всего исправлений: 1)
Ответ на: комментарий от LINUX-ORG-RU

Общее направление верное, да. Если предположить, что все файлы непрерывные, то расположения первого блока будет достаточно. Но если некоторые из файлов фрагментированы, то тогда уже будет не очень.

В идеале нужно выяснить расположение всех блоков, отсортировать уже их и читать последовательно. Пример получения всех блоков файла есть в функции walk_fibmap() в исходниках hdparm. Там как раз генерируется список непрерывных участков, их будет проще сортировать.

Использование FIBMAP будет довольно медленным, потому что нужно вызывать ядро на каждый блок файла. FIEMAP будет быстрее, потому что он отдаёт данные по экстентам.

i-rinat ★★★★★
()
Ответ на: комментарий от vbcnthfkmnth123

А в тех, что требуют — заменять libsteam_api.so на голберговский, а потом тоже запускать без стима.

Без шуток, в основном так и делаю.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Составь список файлов, которые клиент Steam открывает при запуске. Напиши скрипт, который вхолостую читает эти файлы, а уже потом запускает клиент Steam, чтобы им уже всё читалось из кеша в ОЗУ. Желательно отсортировать файлы в порядке размещения на диске.

Уже есть fastwalk, можно не писать. Полезная штука.

В принципе можно со списком не заморачиваться, а читать ~/.local/share/Steam, кроме непосредственно игр.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от i-rinat

Ну попробую ещё сделать вариант с FIEMAP я там местами правда не понял, но попробовать можно

Потом ещё написать узнавалку какие файлы дёргает процесс. А потом всё это вместе скомкать и тестировать ^.^

Пример получения всех блоков файла есть в функции walk_fibmap() в исходниках hdparm.

Так не интересно! И ты сам сказал FIBMAP медленный им разве что предварительные списки порядка обработки файлов составлять, хотя я это и хотел. Но раз FIEMAP более быстрый и вроде не требует установок capsов попробую на нём. Спасиба

Главное не сдуться, а то сегодня уже не так интересно как вчера :3

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 2)
Ответ на: комментарий от CrX

Уже есть fastwalk, можно не писать. Полезная штука.

SSD на параллельных запросах имеют большую производительность. Там чуть ли не идеальное масштабирование, потому что основной затык — в задержках ответов. На HDD такой подход наоборот, роняет производительность в десятки раз, потому что считывающая головка только одна, и ей нужно физически перемещаться.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

SSD на параллельных запросах имеют большую производительность. Там чуть ли не идеальное масштабирование, потому что основной затык — в задержках ответов

На SSD смысла нет, действительно.

На HDD такой подход наоборот, роняет производительность в десятки раз, потому что считывающая головка только одна, и ей нужно физически перемещаться.

Дык именно поэтому и не роняет, а улучшает. fastwalk именно последовательно читает по физическому расположению. Я тупо прогоном оного запуск rtorrent у себя ускорил почти в 3 раза.

А вот конкретно со стимом что-то разницы никакой. То ли у меня HDD слишком быстрый, то ли хз. Там большую часть всякие Waiting for Network и Logging In занимает в моём случае…

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 1)
 ← 1 2
← Кто виноват: KDE Plasma или LibAdwaita?
Desktop
Garuda linux, меню →