<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>Joel, sorry for my late reply!<br>I haven't done such allocation/deallocation in current implementation, it sounds great! But what shall we do to deal with the "unlimited mode"?<br>
 <br></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>