linux-kernel - Re: Problem: Out of memory after 2days with 2GB RAM

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]

Message-Id: <1213290205.3730.2.camel@johannes.berg>
Date:	Thu, 12 Jun 2008 19:03:25 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Tomas Winkler <tomasw@...il.com>
Cc:	Rik van Riel <riel@...hat.com>,
	Zdenek Kabelac <zdenek.kabelac@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	yi.zhu@...el.com, reinette.chatre@...el.com,
	linux-wireless@...r.kernel.org
Subject: Re: Problem: Out of memory after 2days with 2GB RAM


> > Try the patch below. It should improve code generation too.
> >
> > I discussed this with Tomas previously and he says the hw is capable of
> > doing 20 fragments per frame (wonder why, Broadcom can do an unlimited
> > number...) but he complained about the networking stack not being able
> > to.
> 
> This is scatter gather buffers that can be kicked in one DMA transaction.
> 
> Well, the hardware needs to support IP checksumming for that, hence,
> > afaik, only two fragments can ever be used (one for hw header, one for
> > frame)
> This I still don't understand why but everybody is already tired to
> explaining me why.. :) Just need to find time to dig into it.

And you can safely decrease the allocation to 10% as I do in my patch
because once you understand you'll see that you cannot possibly use
more. Hence, you can ack this patch ;)

> > This cuts the allocation to 10%, or (under) a page in all cases.
> 
> Probably. it would be safe to use vmalloc for allocating txb anyway.
> I'll give it a try.

Yeah, but why bother if we can just allocate 10% of the size, waste a
lot less memory etc. mac80211 isn't going to pass in a scatter/gather
frame anyway.

> There was already discussion on LKML about memory allocation problems
> on X86_64, which might explain this regression. This didn't happen
> before.

Doesn't really matter, iwlwifi is _wasting_ this allocation, it cannot
possibly use all those buffers anyway.

The more interesting thing is the pci_alloc_consistent allocation right
below that is also _huge_, but that's because of the stupid hardware
design, or can the hardware cope with having the descriptors non-linear
in memory?

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)