Re: Kernel crash while copying big files since kernel 3.18

[Larry Finger <Larry.Finger@lwfinger.net>]

On 01/25/2015 01:38 PM, François Valenduc wrote:
> Le 11/01/15 18:00, Larry Finger a écrit :
>> On 01/11/2015 08:35 AM, François Valenduc wrote:
>>> Do you still intend to remove the line about allocation failure in the
>>> log ? I made a backup of my root partition compressed with pixz and that
>>> line appeared 1350 times. So I removed the code which add this line. Is
>>> it really expected that it occurs so often ? pixz use multithreading to
>>> compress files and therefore at least 3 of the 4 CPU are used during
>>> around 20 minutes, but are you sure there is no other problems ?
>>
>> Yes, I do intend to remove that line; however, I want to keep it for a
>> while just in case there are other crashes. If this message never
>> appears in that case, then there is another bug.
>>
>> You are, of course, free to remove it from your system. BTW, how much
>> memory do you have?
>>
>> Larry
>>
>>
> Sorry for having forgotten to answer. I have 4 Gb of RAM. Taking a
> backup of a DVD with k9copy also produces so much messages (1479 with a
> patch using rate_limit).
> Is it really expected that skb allocation fails so often ? Could there
> be another problem ?

It is a matter of memory fragmentation. The driver uses a 9100-byte buffer, thus 
the allocation is of order 3. After a system has been running for a while, the 
number of memory blocks of that size may be small. I have not looked at the 
source of k9copy, but I suspect it also allocates large buffers. On a 4G system, 
both DMA and regular allocations come from the same pool of memory.

I have submitted a patch to remove the printout. You should drop it from your 
system.

I am considering a slightly different approach to skb allocation that would 
pre-allocate a number of buffers in a storage pool when the driver was started. 
When the interrupt routine needed one, it would extract it from the pool, which 
would be kept refilled by a work queue routine. If and when I prepare that 
patch, your workload would be a good test. When you used k9copy, was the DVD 
driver local and the destination remote, or were both local? If the latter, you 
are just suffering from memory starvation.

Larry