Похоже, вы испытываете то, что здесь описано:
There is also the chance that a lot of I/O will overwhelm the cache, too. Ever written a lot of data to disk all at once, and seen large pauses on the system while it tries to deal with all that data? Those pauses are a result of the cache deciding that there’s too much data to be written asynchronously (as a non-blocking background operation, letting the application process continue), and switches to writing synchronously (blocking and making the process wait until the I/O is committed to disk)
Это также обсуждается в этой статье LWN . По сути, ваш медленный USB-накопитель может обрабатывать постоянные небольшие записи, но когда ваше задание резервного копирования запускается, оно заполняет кеш виртуальной машины, и теперь вы некоторое время получаете медленные синхронные записи. «echo 3 > /proc/sys/vm/drop _caches» удаляет чистые объекты из этих кешей, позволяя операциям ввода-вывода использовать кеш, тем самым повышая производительность.
Как было предложено в ссылках, поэкспериментируйте с изменением значений для «vm.dirty _*». Например, отношение vm.dirty _фона _и отношение vm.dirty _.
do_IRQ: 1.55 No irq handler for vector
Это сообщение можно найти в исходном файле ядра Linux arch/x86/kernel/irq.c
, так что речь идет об обработке прерываний, характерной для архитектуры x86 -.
/*
* do_IRQ handles all normal device IRQ's (the special
* SMP cross-CPU interrupts have their own specific
* handlers).
*/
__visible unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
struct irq_desc * desc;
/* high bit used in ret_from_ code */
unsigned vector = ~regs->orig_ax;
entering_irq();
/* entering_irq() tells RCU that we're not quiescent. Check it. */
RCU_LOCKDEP_WARN(!rcu_is_watching(), "IRQ failed to wake up RCU");
desc = __this_cpu_read(vector_irq[vector]);
if (!handle_irq(desc, regs)) {
ack_APIC_irq();
if (desc != VECTOR_RETRIGGERED && desc != VECTOR_SHUTDOWN) {
pr_emerg_ratelimited("%s: %d.%d No irq handler for vector\n",
__func__, smp_processor_id(),
vector);
} else {
__this_cpu_write(vector_irq[vector], VECTOR_UNUSED);
}
}
exiting_irq();
set_irq_regs(old_regs);
return 1;
}
Итак, первая цифра (перед точкой )— это идентификатор процессора, создающего отчет, а 55 — это вектор прерывания, как вы обнаружили. Сообщение можно было бы избежать, если бы вектор IRQ находился в состоянии VECTOR_SHUTDOWN
или VECTOR_RETRIGGERED
.
Согласно arch/x86/kernel/apic/vector.c
состояние VECTOR_SHUTDOWN
указывает на вектор прерывания, который был намеренно очищен (, например. аппаратное устройство было остановлено, а его драйвер выгружен контролируемым образом ).
Параметр VECTOR_RETRIGGERED
устанавливается в fixup_irqs()
в конце arch/x86/kernel/irq.c
и, по-видимому, связан с горячим подключением ЦП или, точнее, с пометкой ЦП как отключенного.
Таким образом, ни одно из этих состояний не должно применяться на обычном ПК во время загрузки.
Ваша идея о фиксированном соответствии между номерами векторов прерываний и причинами прерываний была бы применима к архитектуре шины ISA оригинального IBM PC... и спустя некоторое время после этого.
Но где-то в эпоху процессоров 486 и первых Пентиумов,был представлен APIC (Advanced Programmable Interrupt Controller ). Это был один из компонентов, позволяющих нескольким процессорам сосуществовать в архитектуре ПК. Это открыло путь к увеличению количества доступных линий аппаратных прерываний с 15 (пары 8259 контроллеров прерываний, как в первом IBM PC -AT ), в конечном итоге до 224 дискретных аппаратных прерываний. Это позволило проектировать более сложные системы, а также помогло сделать возможными действительно автоматически -конфигурируемые шины.
По сути, либо микропрограмма системы, либо операционная система должны настроить устройство на шине для использования определенной линии прерывания, а затем запрограммировать APIC для направления сигнала прерывания на доступный вектор прерывания в ЦП. Это требует знаний о том, как шина на самом деле подключена к материнской плате, поэтому на практике это почти всегда делается системной прошивкой, и многие исключения предназначены специально для исправления ошибок прошивки.
Первоначально прерывания шины PCI были сопоставлены с прерываниями в стиле ISA -, но когда APIC стали интегрироваться в ЦП, это ограничение можно было снять, уменьшив задержку IRQ и позволив создавать более сложные системы. В шине PCI версии 2.2 были введены прерывания, сигнализируемые сообщениями (MSI ), которые позволяли дискретные аппаратные прерывания без выделенных физических линий прерываний. В PCI Express MSI стал стандартным способом обработки прерываний.
Итак... похоже, что аппаратное обеспечение вашей системы включает в себя активный источник прерываний, направляемых на вектор IRQ 55, но в Linux в настоящее время не загружен драйвер для его обработки. Поскольку пространство конфигурации PCI читается стандартным образом, а Linux читает его, любые устройства на шине PCI (или каналах PCIe )должны быть обнаружены, идентифицированы, и их конфигурация прерывания должна быть известна.
Также может случиться так, что источником IRQ является что-то, что не является устройством PCI, то есть устройством платформы , например, что-то, что является частью набора микросхем системы или подключено к ним с помощью некоего -PCI -совместимый интерфейс. Все такие устройства должны описываться ACPI-таблицами прошивки... но, видимо, в вашем случае этого источника этих IRQ нет.
Я пришел к выводу, что это может быть ошибка прошивки. :Узнайте, предлагает ли HP обновление BIOS для вашей системы. (В данный момент страница загрузки HP для Pavilion Elite m9660de не загружается.)
Согласно этой ветке на форумах Ubuntu , это также может быть аппаратная ошибка в наборе микросхем VIA :, если в вашей системе есть этот набор микросхем, добавление параметра загрузки pci=nomsi,noaer
в GRUB может исправить это.
Если ваше текущее ядро имеет поддержку debugfs
и включен параметр ядра CONFIG _GENERIC _IRQ _DEBUGFS, вы можете получить много информации о состоянии вектора IRQ 55 с помощью следующих команд от root:
mount -t debugfs none /sys/kernel/debug
grep "Vector.*55" /sys/kernel/debug/irq/irqs/*
Это должно сказать вам, какие файлы в этом каталоге упоминают «Вектор :55». Чтение этих файлов должно сказать вам практически все, что известно ядру об этом векторе прерывания.