[GSoC]The overheads caculation of POSIX Key

[Joel Sherrill]

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.
>
>     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&   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/20120822/6e915456/attachment-0001.html>