From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: Adrian Chadd <adrian@freebsd.org>
Cc: linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
nbd@openwrt.org, rodrigue@qca.qualcomm.com
Subject: Re: [RFCv2 1/3] ath9k: add DFS pattern detector
Date: Fri, 30 Mar 2012 10:46:19 +0200 [thread overview]
Message-ID: <4F7572DB.909@neratec.com> (raw)
In-Reply-To: <CAJ-VmokdXbi5BKxqWB5+cwUqPj_iGG+dhKzuxnSKk1y-E9PxSg@mail.gmail.com>
Hi Adrian,
thanks for having a look.
No, if you look into dfs_pri_detector.c, you'll find some words on the
pulse and sequence pools (see DOC below).
Actually, ETSI pulses even have a PRF of up to 4000 pulses per second,
you'd go crazy allocating and freeing them continuously.
With the pools every instance is allocated once during a detector's
lifetime and is then provided to all pri_detectors commonly. The amount
of allocated memory grows up to the maximum simultaneously used
instances. This is limited by numerous means (sliding window, max
tolerated PRF, max pulses per window, etc.).
I did intensive memory allocation tracing when evaluating the detectors
in user-space with valgrind and the absolute maximum memory load in
worst-case (i.e. all DFS channels being flooded with pulse noise
superposed with radar patterns) had an instance count for pulses and
sequences of less than 1.5k, the maximum memory allocated does not
exceed 30kB. While that last number might differ based on the used slab
allocator, it is proven that the pool has a limited growth.
I planned to add some allocation statistics in the debugfs later.
Thanks,
Zefir
On 03/30/2012 08:04 AM, Adrian Chadd wrote:
> Hiya,
>
> I know this is late, but I've been a bit busy elsewhere. :)
>
> Does pulse_queue_enqueue() always allocate a new entry? What situation
> are pulse entries reused?
>
> You likely don't want to be allocating a new pulse entry via malloc()
> for each pulse; it's going to be quite silly when you potentially
> handle > 1,000 false positives a second.
>
>
> Adrian
>
>
> On 23 March 2012 08:34, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> [...]
>> +
>> +/**
>> + * DOC: Singleton Pulse and Sequence Pools
>> + *
>> + * Instances of pri_sequence and pulse_elem are kept in singleton pools to
>> + * reduce the number of dynamic allocations. They are shared between all
>> + * instances and grow up to the peak number of simultaneously used objects.
>> + *
>> + * Memory is freed after all references to the pools are released.
>> + */
>> +static int singleton_pool_references;
>> +static LIST_HEAD(pulse_pool);
>> +static LIST_HEAD(pseq_pool);
>> +
>> [...]
next prev parent reply other threads:[~2012-03-30 8:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-23 15:33 [RFCv2 0/3] ath9k: DFS pattern detector Zefir Kurtisi
2012-03-23 15:34 ` [RFCv2 1/3] ath9k: add " Zefir Kurtisi
2012-03-30 6:04 ` Adrian Chadd
2012-03-30 8:46 ` Zefir Kurtisi [this message]
2012-03-23 15:34 ` [RFCv2 2/3] ath9k: add DFS pattern detector instance to ath_softc Zefir Kurtisi
2012-03-23 15:34 ` [RFCv2 3/3] ath9k: update to DFS pattern detector interface Zefir Kurtisi
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=4F7572DB.909@neratec.com \
--to=zefir.kurtisi@neratec.com \
--cc=adrian@freebsd.org \
--cc=ath9k-devel@lists.ath9k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@openwrt.org \
--cc=rodrigue@qca.qualcomm.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;
as well as URLs for NNTP newsgroup(s).