From: "Tomas Winkler" <tomasw@gmail.com>
To: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "Rik van Riel" <riel@redhat.com>,
"Zdenek Kabelac" <zdenek.kabelac@gmail.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
yi.zhu@intel.com, reinette.chatre@intel.com,
linux-wireless@vger.kernel.org
Subject: Re: Problem: Out of memory after 2days with 2GB RAM
Date: Thu, 12 Jun 2008 20:35:48 +0300 [thread overview]
Message-ID: <1ba2fa240806121035t40d3e8c4laccc768ae337075d@mail.gmail.com> (raw)
In-Reply-To: <1213290205.3730.2.camel@johannes.berg>
On Thu, Jun 12, 2008 at 8:03 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> > 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.
Hope never dies. I actually have seen this speed up the throughput so
I will dig into it 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.
This matter actually for consistent allocation.
> 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?
We talk after your next HW design. How will configure 265 * 16
descriptors separately.
Tomas
next prev parent reply other threads:[~2008-06-12 17:36 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-12 10:07 Zdenek Kabelac
2008-06-12 13:38 ` Rik van Riel
2008-06-12 13:54 ` Johannes Berg
2008-06-12 14:12 ` Zdenek Kabelac
2008-06-12 14:19 ` Johannes Berg
2008-06-12 16:38 ` Tomas Winkler
2008-06-12 15:43 ` Tomas Winkler
2008-06-12 16:35 ` Tomas Winkler
2008-06-12 17:05 ` Johannes Berg
2008-06-12 17:39 ` Tomas Winkler
2008-06-12 17:46 ` Johannes Berg
2008-06-12 18:03 ` Tomas Winkler
2008-06-12 18:15 ` Johannes Berg
2008-06-12 20:11 ` Zdenek Kabelac
2008-06-12 22:17 ` Tomas Winkler
2008-06-13 0:43 ` Andrew Morton
2008-06-12 18:41 ` John W. Linville
2008-06-12 17:03 ` Johannes Berg
2008-06-12 17:35 ` Tomas Winkler [this message]
2008-06-12 17:39 ` Johannes Berg
2008-06-12 17:50 ` Tomas Winkler
2008-06-12 17:10 ` Rik van Riel
2008-06-12 21:30 ` Jiri Slaby
2008-06-12 22:26 ` Tomas Winkler
2008-06-13 14:08 ` Rafael J. Wysocki
2008-06-13 14:15 ` Zdenek Kabelac
2008-06-30 11:30 ` Zdenek Kabelac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ba2fa240806121035t40d3e8c4laccc768ae337075d@mail.gmail.com \
--to=tomasw@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=riel@redhat.com \
--cc=yi.zhu@intel.com \
--cc=zdenek.kabelac@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®