This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/20458] setting maximum arenas via mallopt ( M_ARENA_MAX ) is ineffective after a thread has been created
- From: "mcornish at ca dot ibm.com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 11 Aug 2016 14:44:51 +0000
- Subject: [Bug malloc/20458] setting maximum arenas via mallopt ( M_ARENA_MAX ) is ineffective after a thread has been created
- Auto-submitted: auto-generated
- References: <bug-20458-131@http.sourceware.org/bugzilla/>
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.