On Wed, 2009-10-14 at 19:02 -0700, Frans Pop wrote: > On Wednesday 14 October 2009, reinette chatre wrote: > > We do queue the GFP_KERNEL allocations when there are only a few buffers > > remaining in the queue (8 right now) ... maybe we can make this higher? > > I've tried increasing it to 50. Here's the result for a single test: > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 25 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 48 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 48 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 48 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > __ratelimit: 1 callbacks suppressed > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > __ratelimit: 97 callbacks suppressed > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 44 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > iwlagn 0000:10:00.0: Failed to allocate SKB buffer with GFP_ATOMIC. Only 0 > free buffers remaining. > > This is with current mainline (v2.6.32-rc4-149-ga3ccf63).
> The log file timestamps don't tell much as the logging gets delayed, > so they all end up at the same time. Maybe I should enable the kernel > timestamps so we can see how far apart these failures are. If you can get accurate timing it will be very useful. I am interested to see how quickly it goes from "48 free buffers" to "0 free buffers". Thank you Reinette -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
