[GSoC]The overheads caculation of POSIX Key
joel.sherrill at OARcorp.com
Thu Aug 23 13:09:15 UTC 2012
On 08/22/2012 10:20 PM, Ashi wrote:
> 2012/8/22 Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at oarcorp.com>>
> On 08/21/2012 07:15 PM, Gedare Bloom wrote:
>> On Mon, Aug 20, 2012 at 3:01 AM, Ashi <ashi08104 at gmail.com
>> <mailto:ashi08104 at gmail.com>> wrote:
>> Hi, all. This post is about the overheads calculation of
>> POSIX Key. We haven't reach a resolution about what to do
>> with this. Thanks for any advice!
>> One problem of old POSIX Key is: extra memory is reserved in
>> keys for each thread or task, which can be heavy memory
>> overhead. Now in current one-rbtree implementation of POSIX
>> Key, each key's data isn't allocated until one thread(or
>> task) sets its key data. But RTEMS system still need reserve
>> enough workspace memory for all possible key's data. For
>> example, there are 32 threads and 1 key in system. And only 1
>> thread need key data, then other 31 thread data is not used
>> and reserved. I'm not sure whether it is necessary to provide
>> user a option to set the upper bound of the key data number
>> in system. If it is necessary, I think we can add something
>> like CONFIGURE_MAXIMUM_THREAD_KEY_DATA, it can be from 1 to
>> #max key * #max thread. If we reach the upper bound, we can
>> return ENOMEM in the key setspecific function as the POSIX
>> standard allows.
>> I think it is a good idea to configure the number of keys
>> independent of the number of threads.
> I agree. There are two factors:
> + number of keys
> + number of threads/tasks using keys
> For the first, if you don't _Workspace_Allocate as part of
> creating a key, then it is
> covered by the sizeof(POSIX_Keys_Control). If you simply changed
> just that, the
> existing confdefs.h code does not need to change.
> Each key calling get or set will have a structure allocated via
> This has to be accounted for.
> The "per thread using key" is a number which could be < the number
> of tasks+threads
> or as much as (number of keys * (tasks + threads)) in the case
> where EVERY task/thread
> uses every key.
> I'm a little confused by the the "number of threads/tasks using keys".
> For an concrete example:
> there are 3 Keys, 5 threads in system. And 2 threads use Keys, let's
> say they are thread1, thread2. Thread1 uses 3 keys, thread2 only uses
> 1 key. Then if we use "number of threads using keys", there are 2
> threads using keys, and we get the 2 * 3 key instances in system. But
> actually, there are only 3 + 1 key instances in system.
> So I think the "number of threads using keys" can't be used to compute
> the memory overhead. Or maybe I made a mistake..
In an earlier thread, I used a phrase like "key/thread pairs"
It occurred to me to ask ... do you allocate all of these during
_POSIX_Key_Manager_initialization? You could then have an
RTEMS chain consisting of all of the available "pair instances".
You would _Workspace_Allocate and then call _Chain_Initialize.
Allocation at set would be a _Chain_Get. Deallocation would
be a _Chain_Append. This will have a few advantages:
+ one Workspace allocation during system initialization (GOOD!)
+ Slightly easier to compute size in confdefs.h
+ much faster and WAY more deterministic to allocate
and deallocate than a heap operation.
+ One memory allocation helps reduce fragmentation versus
multiple allocate/free operations
And finally, doing one allocation of a pool of instances is more
in the "RTEMS style" of doing things to stay predictable and favor
operations at system init over object creation over during an
"normal" operation's run-time
>> Another problem: I find there is only maximum keys
>> configuration:CONFIGURE_MAXIMUM_POSIX_KEYS, but how and where
>> does RTEMS determine the proper workspace size for all POSIX
>> Key data?
>> Probably in cpukit/sapi/include/confdefs.h Check for how the
>> macro is used / propagates in that file.
> Specifically at this line of code:
> Note that currently it allocates a POSIX_Keys_Control PLUS the table
> of key values per API.
> I see.
> Based on our discussion, you would be removing that second factor and
> adding another CONFIGURE_xxx symbol corresponding to the number of
> tasks/threads using key instances as discussed above.
>> Best wishes!
>> Zhongwei Yao
> Joel Sherrill, Ph.D. Director of Research& Development
> joel.sherrill at OARcorp.com <mailto:joel.sherrill at OARcorp.com> On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available(256) 722-9985 <tel:%28256%29%20722-9985>
> Best wishes!
> Zhongwei Yao
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel