On Mon, Sep 14, 2009 at 11:01:10AM +0800, Zhu Yi wrote: > 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. > Probably not. I can only assume that moving the location of skb_shared_info such that it is sometimes located after the buffer and sometimes allocated via a separate kmalloc() would be a significant undertaking. > BTW, does SLAB/SLUB guarantee size of multiple PAGE_SIZE __kmalloc() > allocation align on PAGE_SIZE (or 256 bytes) boundary? > Page-aligned. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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
