В моей предыдущей теме я отписался, что я поймал 12309. После багрепорта и небольшой переписки с одним из разрабов - оказалось что это совсем не 12309. А 12309 уже сравнительно давно локализовали и знают в чем причина. Но пока никто не может предложить хорошего решения.
==================
I have a reproducible test sequence for a 12309. It's easy:
Take a _SCRATCHED_ DVD. Put it into the drive and copy all files on it to a
HDD. The bug comes early :)
The system freezes COMPLETELY at the time the drive read a scratched sectors.
I suspect this has more to do with the IDE bus than with the interaction
between the kernel's block layer and the VM.
Try this:
dd if=/dev/dvd of=/dev/null bs=2048
I bet you get the same freezes when it reaches the scratches.
===================
===================
But this is still the 12309 bug, isn't it?
No.
However, this bug report has turned into a dumping ground for anyone
experiencing any lagginess, regardless of cause. The actual bug here is
related to the kernel preferring to evict memory-mapped executable pages when a
process dirties blocks faster than they can be flushed to disk. The apparent
hangs in responsiveness are due to threads (particularly GUI threads)
triggering page faults and being unable to make progress until their code is
re-fetched from disk. The fix should be to block the writing process from
dirtying any more blocks well before the kernel starts evicting mapped
executable pages from memory, but so far no one has been able to make it work
correctly in all cases (afaik).
==============
