[GSoC]The overheads caculation of POSIX Key
ashi08104 at gmail.com
Thu Aug 23 03:20:04 UTC 2012
2012/8/22 Joel Sherrill <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> 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
>> 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
> or as much as (number of keys * (tasks + threads)) in the case where EVERY
> 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..
>> 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& 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...
More information about the devel