<br><br><div class="gmail_quote">2012/8/23 Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div class="im">
On 08/22/2012 10:20 PM, Ashi wrote:
<blockquote type="cite"><br>
<br>
<div class="gmail_quote">2012/8/22 Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div> 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>
</div>
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.
<div><br>
</div>
</div>
</blockquote>
<div>I'm a little confused by the the "number of threads/tasks
using keys". For an concrete example:<br>
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. <br>
So I think the "number of threads using keys" can't be used to
compute the memory overhead. Or maybe I made a mistake..<br>
</div>
</div>
</blockquote>
<br></div>
In an earlier thread, I used a phrase like "key/thread pairs"<br>
<br>
It occurred to me to ask ... do you allocate all of these during <br>
_POSIX_Key_Manager_initialization? You could then have an<br>
RTEMS chain consisting of all of the available "pair instances".<br>
You would _Workspace_Allocate and then call _Chain_Initialize.<br>
Allocation at set would be a _Chain_Get. Deallocation would<br>
be a _Chain_Append. This will have a few advantages:<br>
<br>
+ one Workspace allocation during system initialization (GOOD!)<br>
+ Slightly easier to compute size in confdefs.h<br>
+ much faster and WAY more deterministic to allocate<br>
and deallocate than a heap operation.<br>
+ One memory allocation helps reduce fragmentation versus<br>
multiple allocate/free operations<br>
<br>
And finally, doing one allocation of a pool of instances is more<br>
in the "RTEMS style" of doing things to stay predictable and favor<br>
operations at system init over object creation over during an<br>
"normal" operation's run-time<div><div class="h5"><br></div></div></div></blockquote><div>Hi, all, I have tried to implement this pre-allocation idea. It results a good improvement of keysetspecific operation:). And I have pushed code to github. However, there are some problems:<br>
<br>1. I haven't figured out how to define correct POSIX KEY configuration in confdefs.h, and the code can't pass the key test 07 and key test 08, which are all about unlimited thread/task test. When I run the test, they return as below respectively:<br>
<br>bootcard: work space too big for work area: 80010722 >= 3DA290<br>bootcard: work space too big for work area: 8000B612 >= 3DB3B0<br><br>And I changed the POSIX Key related configuration as below, and other changes can be find in this commit(<a href="https://github.com/ashi08104/rtems/commit/96ba51d0269d0d23708e014f6783669d61fc2962">https://github.com/ashi08104/rtems/commit/96ba51d0269d0d23708e014f6783669d61fc2962</a>). <br>
<br> #ifndef CONFIGURE_MAXIMUM_POSIX_KEYS<br> #define CONFIGURE_MAXIMUM_POSIX_KEYS 0<br> #define CONFIGURE_MAXIMUM_POSIX_KEY_PAIRS 0<br> #define CONFIGURE_MEMORY_FOR_POSIX_KEYS(_keys) 0<br> #else<br>
#ifndef CONFIGURE_MAXIMUM_POSIX_KEY_PAIRS<br> #define CONFIGURE_MAXIMUM_POSIX_KEY_PAIRS \<br> CONFIGURE_MAXIMUM_POSIX_KEYS \<br> * (CONFIGURE_MAXIMUM_POSIX_THREADS + CONFIGURE_MAXIMUM_TASKS)<br> #endif<br>
#define CONFIGURE_MEMORY_FOR_POSIX_KEYS(_keys) \<br> (_Configure_Object_RAM(_keys, sizeof(POSIX_Keys_Control) ) \<br> + CONFIGURE_MAXIMUM_POSIX_KEY_PAIRS \<br> * _Configure_From_workspace(sizeof(POSIX_Keys_Rbtree_node)))<br>
#endif<br><br>2. What shall I do when key deleted or thread deleted? Is just appending the freed key node to the pre-allocation chain enough?<br><br>3. Which version of chain operation should I use during the key nodes pool initialization in _POSIX_Keys_Manager_initialization(), protected chain operation or unprotected chain operation?</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<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>
</div>
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>
</div>
</blockquote>
<div>I see. <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> 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>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div><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>
</div>
<span><font color="#888888">
<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>
</font></span></div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Best wishes!<br>
Zhongwei Yao<br>
<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></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Best wishes!<br>Zhongwei Yao<br><br>