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 21:03:46 +0300 [thread overview]
Message-ID: <1ba2fa240806121103m60a8ffa4ie11850fedc69d13c@mail.gmail.com> (raw)
In-Reply-To: <1213292812.3730.21.camel@johannes.berg>
On Thu, Jun 12, 2008 at 8:46 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> > Well, I disagree, and I'll push my patch as soon as somebody confirms
>> > that it doesn't break anything.
>>
>> Remember you are not a maintainer of this driver and second we are
>> open to all suggestions you don't have to use this kind of
>> statements...
>
> Yeah, you're right, I can't really do that. But I can submit the patch
> to akpm, and I'm sure he'll take it after you provide your counter
> argument about hope never dying again ;)
Here you go again
> Frankly, I don't see why you're so opposed to this patch even if it
> doesn't solve anything it probably leads to better code generation and
> using a lot less memory.
I'm not against it. You;v decided that I'm fighting you because I gave
another solution.
Frankly we probably don't need this allocation at all. maybe one skb
is just enough
even with my never dying hope all fragments are in skb fragment list.
This still probably won't save pci memory allocation problem
Tomas
> Also, I know you cannot actually need those descriptors since mac80211
> will never ever pass such frames, and _that_ is an area I do have at
> least some influence over, so I'll surely notice when that changes.
>
>> >> > There was already discussion on LKML about memory allocation problems
>> >> > on X86_64, which might explain this regression. This didn't happen
>> >> > before.
>> >>
>> >> This is the thread title if you are interested.
>> >> 'x86/kernel/pci_dma.c: gfp |= __GFP_NORETRY'
>> >
>> > Like I said, it doesn't matter, there's no need to _waste_
>> > 18*256*sizeof(void *) bytes memory.
>>
>> It does matter this is not pci allocation we are saving in your patch.
>
> Well, thing is, my patch saves 18 KiB memory on 32-bit and 36 on 64-bit,
> so I think we should merge it regardless. Yes, the pci allocation is
> icky, and yes, it would be good to just do it once instead of over and
> over again, but even if you change it to do _all_ those allocations just
> once we should not be wasting those 18/36 KiB memory for nothing.
>
> johannes
>
next prev parent reply other threads:[~2008-06-12 18:04 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 [this message]
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
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=1ba2fa240806121103m60a8ffa4ie11850fedc69d13c@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®