Well, this makes little sense, right? I mean, if just a normal
filesystem I/O produces more I/O requests than the machine can
handle, - it means the kernel is broken. It shouldn't let the
queue to grow without bounds.
The hardware is quite capable - 14-drives raid10 array works
pretty fast, that is.
which should be quite huge leakage, as it happens almost immediately,
on a freshly booted system.
Just tried this option. Gzip is working for 15 minutes already, --
previously the system hanged within a first minute, usually first
10 secs. It seems it will survive the test.
It's difficult to say if it was ok with older kernels. I'll try anyway.
The thing is that this very workload is new for this machine. Once
upon a time it hanged in a very similar way, but we had no time to debug
the issue and just ignored it, in a hope for the best.
By the way, is there something to look at, for swiommu space leaks --
like slabinfo for example...?
Thanks!
/mjt
--
