This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]