[Bug malloc/20458] setting maximum arenas via mallopt ( M_ARENA_MAX ) is ineffective after a thread has been created

mcornish at ca dot ibm.com sourceware-bugzilla@sourceware.org
Thu Aug 11 14:45:00 GMT 2016


https://sourceware.org/bugzilla/show_bug.cgi?id=20458

--- Comment #1 from Michael Cornish <mcornish at ca dot ibm.com> ---
I think we could just switch the conditions around and always check a non-0
configured setting.  I'm assuming the purpose of preserving narenas_limit is to
prevent repeated calls to __get_nprocs.  

looking at 2.24 ..
from
       /* Nothing immediately available, so generate a new arena.  */
       if (narenas_limit == 0)
         {
           if (mp_.arena_max != 0)
             narenas_limit = mp_.arena_max;
           else if (narenas > mp_.arena_test)
             {
               int n = __get_nprocs ();

to
       /* Nothing immediately available, so generate a new arena.  */
       if (mp_.arena_max != 0)
         narenas_limit = mp_.arena_max;
       else if (narenas_limit == 0 && narenas > mp_.arena_test)
         {
           int n = __get_nprocs ();

This proposal doesn't consider the odd case of a dynamic switch from non-0 to
0, which is no different in either case (still ineffective after thread has
been created).

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list