From: Ben Greear <greearb@candelatech.com>
To: bruce m beach <brucembeach@gmail.com>
Cc: Oleksij Rempel <linux@rempel-privat.de>, linux-wireless@vger.kernel.org
Subject: Re: ath9k_htc kernel driver regression affecting throughput
Date: Thu, 22 Sep 2016 06:34:54 -0700 [thread overview]
Message-ID: <57E3DDFE.20104@candelatech.com> (raw)
In-Reply-To: <CAArymC=VT+1E=-ug1yaVquW0jVvbFfZ0USzRcsRD62tSR-9FRA@mail.gmail.com>
On 09/21/2016 09:53 PM, bruce m beach wrote:
> memory will be very tight. There is 160k or known ram and bits and pieces
> elsewhere. The rom is 24k (maximum). I currently am not to worried about
> it. (although I am watching it)
> bruce
Probably you know this...but check structs for memory holes, unused
fields (write only, for instance) and other wastes.
ath10k firmware was full of needless memory bloat in those areas.
Global pointers can be used in some cases to help, but mysteriously
seem to cause more instruction RAM in some cases.
Watch 'instruction ram' usage: Changing code to use a bitfield may save
some BSS ram, but may easily use far more instruction ram than what you
saved with the bitfield.
Good luck!
Thanks,
Ben
>
> On 9/21/16, Ben Greear <greearb@candelatech.com> wrote:
>>
>>
>> On 09/21/2016 08:34 PM, bruce m beach wrote:
>>
>>>>> i.e a lable that the code jumps to and nothing else. At this point I
>>>>> have
>>>>> added VendorCommand(), and a debugger via ep0. ( ep0 is a good choice
>>>>> since it is available a boot, no matter what) and over the next few
>>>>> months I am going to move ->all<- the rom code into ram starting with
>>>>> the USB subsystem.
>>
>> Have you investigated whether you have enough RAM to do this?
>>
>> I haven't looked at ath9k_htc, but in general, that type of architecture
>> is tight on RAM in my experience.
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb@candelatech.com>
>> Candela Technologies Inc http://www.candelatech.com
>>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2016-09-22 13:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 3:43 ath9k_htc kernel driver regression affecting throughput bruce m beach
2016-09-21 4:30 ` Oleksij Rempel
2016-09-22 3:34 ` bruce m beach
2016-09-22 4:18 ` Ben Greear
2016-09-22 4:53 ` bruce m beach
2016-09-22 13:34 ` Ben Greear [this message]
2016-09-22 17:11 ` Oleksij Rempel
-- strict thread matches above, loose matches on Subject: below --
2016-09-17 15:52 bruce m beach
2016-09-17 16:14 ` Oleksij Rempel
2016-09-17 16:23 ` Oleksij Rempel
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=57E3DDFE.20104@candelatech.com \
--to=greearb@candelatech.com \
--cc=brucembeach@gmail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linux@rempel-privat.de \
/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;
as well as URLs for NNTP newsgroup(s).