<p>Note that configuration changes require user doc and release note update at wiki</p>
<div class="gmail_quote">On Aug 22, 2012 7:08 AM, "Joel Sherrill" <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
On 08/21/2012 07:15 PM, Gedare Bloom wrote:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">On Mon, Aug 20, 2012 at 3:01 AM, Ashi <span dir="ltr"><<a href="mailto:ashi08104@gmail.com" target="_blank">ashi08104@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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!<br>
<br>
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.<br>
<br>
</blockquote>
<div>I think it is a good idea to configure the number of keys
independent of the number of threads.<br>
</div>
</div>
</blockquote>
I agree. There are two factors:<br>
<br>
+ number of keys <br>
+ number of threads/tasks using keys<br>
<br>
For the first, if you don't _Workspace_Allocate as part of creating
a key, then it is<br>
covered by the sizeof(POSIX_Keys_Control). If you simply changed
just that, the<br>
existing confdefs.h code does not need to change.<br>
<br>
Each key calling get or set will have a structure allocated via
_Workspace_Allocate.<br>
This has to be accounted for. <br>
<br>
The "per thread using key" is a number which could be < the
number of tasks+threads<br>
or as much as (number of keys * (tasks + threads)) in the case where
EVERY task/thread<br>
uses every key.<br>
<blockquote type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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? <br>
<br>
</blockquote>
<div>Probably in cpukit/sapi/include/confdefs.h Check for how
the macro is used / propagates in that file.<br>
<br>
</div>
</div>
</blockquote>
Specifically at this line of code:<br>
<br>
<a href="http://git.rtems.org/rtems/tree/cpukit/sapi/include/confdefs.h#n1703" target="_blank">http://git.rtems.org/rtems/tree/cpukit/sapi/include/confdefs.h#n1703</a><br>
<br>
Note that currently it allocates a POSIX_Keys_Control PLUS the table<br>
of key values per API. <br>
<br>
Based on our discussion, you would be removing that second factor
and<br>
adding another CONFIGURE_xxx symbol corresponding to the number of<br>
tasks/threads using key instances as discussed above.<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">links:<br>
[0] <a href="http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_setspecific.html" target="_blank">http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_setspecific.html</a><span><font color="#888888"><br>
-- <br>
Best wishes!<br>
Zhongwei Yao<br>
<br>
</font></span></blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre cols="72">--
Joel Sherrill, Ph.D. Director of Research& Development
<a href="mailto:joel.sherrill@OARcorp.com" target="_blank">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available <a href="tel:%28256%29%20722-9985" value="+12567229985" target="_blank">(256) 722-9985</a>
</pre>
</div>
</blockquote></div>