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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
