[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