From: "Tomas Winkler" <tomasw@gmail.com>
To: "Zdenek Kabelac" <zdenek.kabelac@gmail.com>
Cc: "Johannes Berg" <johannes@sipsolutions.net>,
"Rik van Riel" <riel@redhat.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: Fri, 13 Jun 2008 01:17:14 +0300 [thread overview]
Message-ID: <1ba2fa240806121517p6ef1e117ofd940ad763195a0d@mail.gmail.com> (raw)
In-Reply-To: <c4e36d110806121311n64890e17h67f49c32481fbb28@mail.gmail.com>
On Thu, Jun 12, 2008 at 11:11 PM, Zdenek Kabelac
<zdenek.kabelac@gmail.com> wrote:
> 2008/6/12 Johannes Berg <johannes@sipsolutions.net>:
>>
>>> I'm not against it. You;v decided that I'm fighting you because I gave
>>> another solution.
>>
>> Ok, no, I'm not saying you shouldn't rewrite all the code to get rid of
>> it, but I think you can use a patch like mine interim as such a rewrite
>> is unlikely to go into 2.6.26, is it?
>>
>>> Frankly we probably don't need this allocation at all. maybe one skb
>>> is just enough
>>
>> That would be nice, indeed.
>>
>>> even with my never dying hope all fragments are in skb fragment list.
>>
>> :)
>>
>>> This still probably won't save pci memory allocation problem
>>
>> Yeah, true, that one needs to be done, but it could probably be done
>> only once when hw is probed rather than every time it is brought up.
>> Most likely not something you'll get to fix in 2.6.26 either though.
>
>
> Well - it's great that there will be saved few kB in allocation of
> never used pointers in iwl driver - but does this really solve the
> problem that kernel gets relatively quickly out of memory for
> allocations of this size - I guess iwl isn't the only driver
> requesting 32 sequential pages.
>
> Is it possible to track how this memory gets fragment/lost - who owns
> the block and why they are not back in the pool?
>
> btw with 8hour uptime at this moment I can see this:
>
> DMA: 26*4kB 37*8kB 72*16kB 65*32kB 3*64kB 0*128kB 0*256kB 0*512kB
> 0*1024kB 0*2048kB 1*4096kB = 7920kB
> DMA32: 203*4kB 79*8kB 26*16kB 11*32kB 6*64kB 9*128kB 3*256kB 2*512kB
> 2*1024kB 0*2048kB 0*4096kB = 7588kB
>
> so at this moment I can see quiet a lot of free DMA memory - but in my
> trace at the thread beginig after several suspend/resumes this memory
> was gone....
Currently the driver frees the memory on down and allocates it back on
up. This is done even in initial
reset for sake of flow simplicity.
I'm not sure yet why the memory is actually accumulating, whether the
bug is in the driver or memory system is not clear to me yet. I
haven't seen this on older kernels or driver.
As I wrote I'm also polishing a patch that doesn't do this free-alloc
loop hope this will remedy somehow this problem. It has a drawback as
it will hold on memory even if devices is down.
Tomas
next prev parent reply other threads:[~2008-06-12 22:17 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 [this message]
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
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=1ba2fa240806121517p6ef1e117ofd940ad763195a0d@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®