Менеджмент памяти ядром — это тема, скажем, примерно на 700 страниц, тут в двух словах не пересказать, не то, что «аршином измерить». Погуглите слова «linux kernel memory management pdf», если на kernel(dot)org отправит, то это то, меня, к сожалению, местные крепкие ребята лишили возможности постить ссылки (чем-то не понравилась, возможно резкостью выражений, моя приязнь к С и неприязнь к С++ в одном из тредов Интела). Не факт, что суммирование процессами занятой памяти даст адекватную картину, но это, мне кажется, ближе к теме. Ну и сама по себе задача измерить доступную память очень зыбка, даже Гугл не решается ее измерять перед компиляцией Хромиума в Генте, оценивает свободное место на диске и общее количество оперативки.
Пользовательская документация, мне так кажется, не поможет в таком болезненном для ядра вопросе. Алгоритмов несколько, в Линуксе зависит еще от аллокатора, выбранного при настройке исходников ядра, несколько уровней зонирования, buddy system, slab, помимо pages на page frames, необходимо, чтобы память сильно не фрагментировалась, многое хранится в ней до самого запроса на освобождение и т.д. Лучше сразу исходники читать и комментарии непосредственно к коду ядра. Таким методом интроспекции (top и malloc) вряд ли можно даже на интуитивном уровне догадаться, что внутри происходит.
QEMU also supports a wide variety of caching modes. If you're using raw volumes or partitions, it is best to avoid the cache completely, which reduces data copies and bus traffic
OShapovalov, «векторизация» вот это я подразумевал выше под «попробовать другие способы». Это правильней с терминологической и практической точки зрения. У меня еще возник вопрос по ходу чтения этого комментария с упоминанием про fma-инструкции и кеша. Зачем там x86 архитектура, если устройство предназначено для плавающей точки. Ведь на OpenCL и CUDA можно самому регулировать что в какую память пойдет и на какие вычислительные единицы. Получается, что теряется гибкость и контроль. Есть ли у этого какие-то плюсы, кроме того, что там Линукс?
Ну я вот и спрашиваю про параллельный вариант. На одном то юните алгоритм сам по себе быстрее, чем больше юнитов, тем больше разница в абсолютных значениях. Я так понял, что проблема, которая, видимо, общая для всех алгоритмов, которые распараллеливают рекурсию: неравномерность вычислений, которая затормаживает быстрые потоки на моменте синхронизации и несоответствие количества вычислений количеству юнитов. А не пробовали другие методы использовать, что нибудь а ля thread pool для этих задач?
Про шумы в IRQ и про контроллер понятно, меня удивляет, что официальная таблица скрывает от нас правду. И в коде ядра обработчик этого прерывания все таки есть.
do_spurious_interrupt_bug(struct pt_regs *regs, long error_code)
{
conditional_sti(regs);
#if 0
/* No need to warn about this any longer. */
pr_info("Ignoring P6 Local APIC Spurious Interrupt Bug...\n");
#endif
}
И еще про табличку исключений:
15 Зарезервировано Intel, не предназначено для использования
Смотрю в исходники, теперь уже в хендлеры исключений (arch / x86 / include / asm / traps.h):
X86_TRAP_SPURIOUS, /* 15, Spurious Interrupt */
Интернет отправляет в Вики про The Intel 8259 is a Programmable Interrupt Controller (PIC) designed for the Intel 8085 and Intel 8086 microprocessors.
Spurious interrupts[edit]
The 8259 generates spurious interrupts in response to a number of conditions.
The first is an IRQ line being deasserted before it is acknowledged. This may occur due to noise on the IRQ lines. In edge triggered mode, the noise must maintain the line in the low state for 100 ns. When the noise diminishes, a pull-up resistor returns the IRQ line to high, thus generating a false interrupt. In level triggered mode, the noise may cause a high signal level on the systems INTR line… итд.
Написано, что не предназначено для использования, но почему тогда хендлер в исходниках ядра есть для этого исключения?
Еще про табличку исключений:
1 #DB Зарезервировано Только для использования Intel
По моим данным:
1- “Debug” (trap or fault)
Raised when the TF flag of eflags is set (quite useful to implement single-step
execution of a debugged program) or when the address of an instruction or
operand falls within the range of an active debug register.
И в исходниках (ядро 3.18.19) все в том же entry_64.S вот какую строчку нашел:
idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
Все же я за kgdb на рабочей машине, и дебажить на любом таргете ядро с символами. Кстати сам Торвальдс не любит дебаггеры, gdb использует как дизассемблер на стероидах, дескать без них разработчик более детально вникает в суть кода, решая проблему.
У меня хост — Линукс, ВМ — тоже Линукс (KVM). Редактирую файлы на гостевой. Для синхронизации файлов я использую шелл-скрипт, использующий inotify-tools, который при каждом изменении файла на гостевой машине запускает rsync по ssh, работает мгновенно. Для Windows есть наверняка какие-то вотчеры, которые могут по изменению файлов какой-то код запускать, BAT-файлы какие-нибудь можно написать для автоматизации.
До того, когда перешел полностью на Линукс и консольный Vim в разработке, использовал MacOS и PyCharm, в PyCharm были настройки что-то типа Creating a Remote Server Configuration, Customizing Upload/Download, там можно было по FTP, SFTP конфигурировать синхронизацию. Работало, насколько я помню, быстро. Был Suse в VMWare Player/Workstation — точно так же, через PyCharm люди, работавшие в Windows, синхронизацию настраивали. Еще наш техдир в VMWare виртуальный HDD не разбивал на несколько маленьких файлов, а использовал один большой, говорил, что так быстрее.
NFS пробовал использовать для других задач, сложно сказать что-то определенное, помню только, что по вай-фаю медленно большие файлы передавались, для разработки возможно подойдет, т.к. требования для передачи данных другие.
Не знаю, насколько это может пригодится в Vagrant, я так понимаю, у них там много своих скриптов для удобства. Возможно у них самих есть какие-то готовые решения.
Центральные процессоры и графические ядра современных устройств, работающих под управлением Android, способны на многое.
От Android там только HAL, непосредственно управляет процессорами и периферией в SoC ядро Linux, Андроид тут добавляет Java-прослойку. Впрочем она и определяет «способность на многое» количеством Java-программистов. Тем не менее познавательная информация про интеграцию OpenCL kernels в приложения для Андроид.
По размеру слова на таргете. А ошибка с передачей размера не отдельным аргументом — действительно детская ошибка, не знал что в С++ она распространена, думал, что они со своим STL уже и забыли про массивы.
Параллельные алгоритмы имеют математическую модель (вводится в нотацию переменная кол-ва процессоров), свои паттерны и рассматриваются вопросы влияния времени синхронизации нитей на время вычисления. Но фактически формальные алгоритмы к которым можно с уверенностью применить математическую модель актуальны для SIMD и GPU, где можно точно распределить на вычислительные единицы какие-то операции и учесть время трансфера данных из хоста в память GPU, на CPU все сложнее, время на нити (легковесные процессы) scheduler операционной системы раздает и решает.
А собеседования разные бывают, все это частные случаи, например на одном я общался в светском формате с человеком за чашечкой чая про ассемблер и теорию конечных автоматов, на другом мы только обсудили объем работ и цену за час работы.
Странное противопоставление и перевод названия заметки, если он подразумевает общий случай. На этапе проектирования приоритетны Organizational Skill, на этапе оптимизации потребления ресуров (память, время вычислений) приоритетно Algorithmic Wizardry.
Интересно, им кто-то пользуется?
15 Зарезервировано Intel, не предназначено для использования
Смотрю в исходники, теперь уже в хендлеры исключений (arch / x86 / include / asm / traps.h):
X86_TRAP_SPURIOUS, /* 15, Spurious Interrupt */
Интернет отправляет в Вики про The Intel 8259 is a Programmable Interrupt Controller (PIC) designed for the Intel 8085 and Intel 8086 microprocessors.
Spurious interrupts[edit]
The 8259 generates spurious interrupts in response to a number of conditions.
The first is an IRQ line being deasserted before it is acknowledged. This may occur due to noise on the IRQ lines. In edge triggered mode, the noise must maintain the line in the low state for 100 ns. When the noise diminishes, a pull-up resistor returns the IRQ line to high, thus generating a false interrupt. In level triggered mode, the noise may cause a high signal level on the systems INTR line… итд.
Написано, что не предназначено для использования, но почему тогда хендлер в исходниках ядра есть для этого исключения?
1 #DB Зарезервировано Только для использования Intel
По моим данным:
1- “Debug” (trap or fault)
Raised when the TF flag of eflags is set (quite useful to implement single-step
execution of a debugged program) or when the address of an instruction or
operand falls within the range of an active debug register.
И в исходниках (ядро 3.18.19) все в том же entry_64.S вот какую строчку нашел:
idtentry debug do_debug has_error_code=0 paranoid=1 shift_ist=DEBUG_STACK
До того, когда перешел полностью на Линукс и консольный Vim в разработке, использовал MacOS и PyCharm, в PyCharm были настройки что-то типа Creating a Remote Server Configuration, Customizing Upload/Download, там можно было по FTP, SFTP конфигурировать синхронизацию. Работало, насколько я помню, быстро. Был Suse в VMWare Player/Workstation — точно так же, через PyCharm люди, работавшие в Windows, синхронизацию настраивали. Еще наш техдир в VMWare виртуальный HDD не разбивал на несколько маленьких файлов, а использовал один большой, говорил, что так быстрее.
NFS пробовал использовать для других задач, сложно сказать что-то определенное, помню только, что по вай-фаю медленно большие файлы передавались, для разработки возможно подойдет, т.к. требования для передачи данных другие.
Не знаю, насколько это может пригодится в Vagrant, я так понимаю, у них там много своих скриптов для удобства. Возможно у них самих есть какие-то готовые решения.
От Android там только HAL, непосредственно управляет процессорами и периферией в SoC ядро Linux, Андроид тут добавляет Java-прослойку. Впрочем она и определяет «способность на многое» количеством Java-программистов. Тем не менее познавательная информация про интеграцию OpenCL kernels в приложения для Андроид.
А собеседования разные бывают, все это частные случаи, например на одном я общался в светском формате с человеком за чашечкой чая про ассемблер и теорию конечных автоматов, на другом мы только обсудили объем работ и цену за час работы.
и перевод названия заметки, если он подразумевает общий случай. На этапе проектирования приоритетны Organizational Skill, на этапе оптимизации потребления ресуров (память, время вычислений) приоритетно Algorithmic Wizardry.