Re: iwlagn: order 2 page allocation failures

[Zhu Yi]

On Fri, 2009-09-11 at 16:47 +0800, Mel Gorman wrote:
> On Thu, Sep 10, 2009 at 02:14:50PM -0700, reinette chatre wrote:
> > On Thu, 2009-09-10 at 02:02 -0700, Mel Gorman wrote:
> > 
> > > 
> > > As a total aside, there is still the problem that the driver is depending on
> > > order-2 allocations. On systems without swap, the allocation problem could be
> > > more severe as there are fewer pages the system can use to regain contiguity.
> > 
> > I looked more at the implementation and hardware interface but I do not
> > see a way around this. We have to provide 8k buffer to device, and we
> > have to make sure it is aligned. 
> > 
> 
> That would imply an order-1 allocation instead of an order-2 though so
> it would appear than we are being worse than we have to. It would appear
> to be because of this +256 bytes that goes onto every buffer.
> 
> > Do you have any suggestions?
> > 
> 
> Nothing concrete. Finding an alternative to having the socket buffer
> 8192+256 to make it an order-1 allocation would be an improvement but I
> don't know how that should be tackled. Lacking the hardware, I can't
> experiment myself :(

Essentially, the hardware only requires an order-1 allocation aligned on
256 bytes boundary. But as it is used as an SKB, a trailing struct
skb_shared_info is added. This forces us to both increase the order and
do alignment ourselves. I believe some improvement could be done here.
But it should not be an easy one.

BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc()
allocation align on PAGE_SIZE (or 256 bytes) boundary?

Thanks,
-yi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/