Zfs: Запрос функции: кэшированный и параллельный DKMS

Похоже, вы пытаетесь заново реализовать gentoo/funtoo (или аналогичные дистрибутивы на основе исходного кода), в которых уже решена обработка общесистемных флагов компиляции (и это может быть только количество параллельно работающих gcc).

ИМХО, не стоит вмешиваться в системные настройки компилятора. В случае, если длительное время сборки является проблемой для пользователя DKMS... разумным подходом будет добавление руководства ("ускорение компиляции").

Вы уже можете сделать то, что запрашиваете, создав файл конфигурации DKMS. Посмотрите страницу man для dkms в разделе _DKMS.CONF_ и _DKMS.CONF OVERRIDES_ для получения информации о том, как указать директивы для переопределения параметров, указанных в dkms.conf , который поставляется с пакетом DKMS. .

Например, для RHEL/CentOS/Fedora и ZFS 0.7.13, если вы посмотрите на файл dkms.conf , поставляемый с RPM (например, /var/lib/dkms/spl/0.7.13/source/dkms.conf и /var/lib/zfs/0.7.13/source/dkms.conf ), вы можете видеть, что сборки SPL и ZFS используют только MAKE[0]="make" . Чтобы переопределить это, создайте файлы /etc/dkms/spl.conf и /etc/dkms/zfs.conf . В файлах вы можете указать команду MAKE для использования. Чтобы просто включить параллельную сборку, используйте:

MAKE[0]="make --jobs"

Это будет запускать все задания параллельно и не ограничивать их количество. Лучшим вариантом было бы ограничить количество процессоров на машине:

MAKE[0]="make --jobs $(nproc)"

Однако ничего из вышеперечисленного не требуется, так как современные версии DKMS по умолчанию запускают make параллельно с количеством заданий, равным количеству процессоров в системе. Посмотрите на /usr/sbin/dkms в вашей системе. У меня там такие строчки:

get_num_cpus()
{
   # use nproc(1) from coreutils 8.1-1+ if available, otherwise single job
   if [ -x /usr/bin/nproc ]; then
        nproc
   else
        echo "1"
  fi
}
...
do_build()
{
    ...
    local the_make_command="${make_command/#make/make -j$parallel_jobs KERNELRELEASE=$kernelver}"

    invoke_command "{ $the_make_command; } >> $dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command" background || \
        report_build_problem 10 $"Bad return status for module build on kernel: $kernelver ($arch)" \
        $"Consult $dkms_tree/$module/$module_version/build/make.log for more information."
...
parallel_jobs=${parallel_jobs:-$(get_num_cpus)}

# Make sure we're not passing -j0 to make; treat -j0 as just "-j"
[[ "$parallel_jobs" = 0 ]] && parallel_jobs=""

Поскольку spl.dkms и zfs.dkms задают MAKE[0]="make" , dkms уже должен параллельно выполнять команду make .

Включение ccache описано на странице man . Если вы используете метод символических ссылок, пока /usr/local/bin находится в вашем пути до /usr/bin , ccache будет использоваться автоматически. Если вы хотите использовать метод префиксной команды, вы должны переопределить CC в вашей локальной среде на что-то вроде ccache gcc .

Я подозреваю, что вы обнаружите, что ни одно из этих изменений не имеет большого значения. Компилировать нужно не так много файлов, а gcc работает довольно быстро (и DKMS уже должен работать make параллельно). Мой опыт показывает, что этап сборки не занимает много времени. Шаги перед сборкой (например, configure ) и шаги после сборки (например, dracut ) занимают много времени на моих машинах.

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

14 октября 2019 г., 14:58, Кристофер Вольц написал:

Я подозреваю, что вы обнаружите, что ни одно из этих изменений не имеет большого значения. Компилировать нужно не так много файлов, а gcc работает довольно быстро (а DKMS уже должен запускать make параллельно). Мой опыт показывает, что этап сборки не занимает много времени. Шаги перед сборкой (например, configure ) и шаги после сборки (например, dracut ) занимают много времени на моих машинах.

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

Также обратите внимание, что самая большая часть этих шагов перед сборкой — это определение
какие интерфейсы есть у ядра, и что только что было (в основном)
распараллелен в master. Наше время настройки стены сократилось с ~ 2,5 минут.
до ~20 секунд. Это была самая большая часть создания модулей и
пользовательское пространство. Я подозреваю, что как только это изменение попадет в Debian, DKMS
сборка модулей также будет значительно ускорена на системах с более чем
скажем 2 или 4 ядра.

Вы уже можете сделать то, что запрашиваете, создав файл конфигурации DKMS. Посмотрите страницу man для dkms в разделе _DKMS.CONF_ и _DKMS.CONF OVERRIDES_ для получения информации о том, как указать директивы для переопределения параметров, указанных в dkms.conf , который поставляется с пакетом DKMS. .

Например, для RHEL/CentOS/Fedora и ZFS 0.7.13, если вы посмотрите на файл dkms.conf , поставляемый с RPM (например, /var/lib/dkms/spl/0.7.13/source/dkms.conf и /var/lib/zfs/0.7.13/source/dkms.conf ), вы можете видеть, что сборки SPL и ZFS используют только MAKE[0]="make" . Чтобы переопределить это, создайте файлы /etc/dkms/spl.conf и /etc/dkms/zfs.conf . В файлах вы можете указать команду MAKE для использования. Чтобы просто включить параллельную сборку, используйте:

MAKE[0]="make --jobs"

Это будет запускать все задания параллельно и не ограничивать их количество. Лучшим вариантом было бы ограничить количество процессоров на машине:

MAKE[0]="make --jobs $(nproc)"

Однако ничего из вышеперечисленного не требуется, так как современные версии DKMS по умолчанию запускают make параллельно с количеством заданий, равным количеству процессоров в системе. Посмотрите на /usr/sbin/dkms в вашей системе. У меня там такие строчки:

get_num_cpus()
{
   # use nproc(1) from coreutils 8.1-1+ if available, otherwise single job
   if [ -x /usr/bin/nproc ]; then
        nproc
   else
        echo "1"
  fi
}
...
do_build()
{
    ...
    local the_make_command="${make_command/#make/make -j$parallel_jobs KERNELRELEASE=$kernelver}"

    invoke_command "{ $the_make_command; } >> $dkms_tree/$module/$module_version/build/make.log 2>&1" "$the_make_command" background || \
        report_build_problem 10 $"Bad return status for module build on kernel: $kernelver ($arch)" \
        $"Consult $dkms_tree/$module/$module_version/build/make.log for more information."
...
parallel_jobs=${parallel_jobs:-$(get_num_cpus)}

# Make sure we're not passing -j0 to make; treat -j0 as just "-j"
[[ "$parallel_jobs" = 0 ]] && parallel_jobs=""

Поскольку spl.dkms и zfs.dkms задают MAKE[0]="make" , dkms уже должен параллельно выполнять команду make .

Включение ccache описано на странице man . Если вы используете метод символических ссылок, пока /usr/local/bin находится в вашем пути до /usr/bin , ccache будет использоваться автоматически. Если вы хотите использовать метод префиксной команды, вы должны переопределить CC в вашей локальной среде на что-то вроде ccache gcc .

Я подозреваю, что вы обнаружите, что ни одно из этих изменений не имеет большого значения. Компилировать нужно не так много файлов, а gcc работает довольно быстро (и DKMS уже должен работать make параллельно). Мой опыт показывает, что этап сборки не занимает много времени. Шаги перед сборкой (например, configure ) и шаги после сборки (например, dracut ) занимают много времени на моих машинах.

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

@cvoltz Вау, мне стыдно, что я отправил запрос функции, не углубившись в то, что вы предоставили ... вы правы, это оба жизнеспособных варианта, которые удерживают право собственности от ZFS и даже от управления пакетами. вещи (именно там я думал, что эта тема пойдет).

И да, после просмотра журналов... вы правы... этап конфигурации для меня сильно отстает, не говоря уже о компиляции.

В любом случае, я ценю ваш ответ, как и все остальные... Я закрою это... извините за шум!

Ваше здоровье
Крис