[GSoC]The overheads caculation of POSIX Key

Gedare Bloom gedare at rtems.org
Wed Aug 22 17:38:25 UTC 2012


Note that configuration changes require user doc and release note update at
wiki
On Aug 22, 2012 7:08 AM, "Joel Sherrill" <joel.sherrill at oarcorp.com> wrote:

>  On 08/21/2012 07:15 PM, Gedare Bloom wrote:
>
>
>
> On Mon, Aug 20, 2012 at 3:01 AM, Ashi <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.
>
>
>
>> 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.
>
> 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&  Developmentjoel.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/20120822/299b4ea5/attachment-0001.html>


More information about the devel mailing list