linux-kernel - Re: iwlagn: order 2 page allocation failures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Sep 2009 14:06:12 +0100
From:	Mel Gorman <mel@....ul.ie>
To:	Zhu Yi <yi.zhu@...el.com>
Cc:	"Chatre, Reinette" <reinette.chatre@...el.com>,
	Frans Pop <elendil@...net.nl>,
	Larry Finger <Larry.Finger@...inger.net>,
	"John W. Linville" <linville@...driver.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"ipw3945-devel@...ts.sourceforge.net" 
	<ipw3945-devel@...ts.sourceforge.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"cl@...ux-foundation.org" <cl@...ux-foundation.org>,
	"Krauss, Assaf" <assaf.krauss@...el.com>,
	Johannes Berg <johannes@...solutions.net>,
	"Abbas, Mohamed" <mohamed.abbas@...el.com>
Subject: Re: iwlagn: order 2 page allocation failures

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/