[GSoC]The overheads caculation of POSIX Key

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[0] 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
>     _Workspace_Allocate.
>     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:
>
>     http://git.rtems.org/rtems/tree/cpukit/sapi/include/confdefs.h#n1703
>
>     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.
>
>
>>         links:
>>         [0]
>>         http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_setspecific.html
>>         -- 
>>         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...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120823/cf3a0de3/attachment-0001.html>