MPS issue job003812

TitleMVAlloc taking significant CPU in profiles
Assigned userDavid Lovemore
DescriptionMVAlloc shows up in profiles of CET, as taking around 5% of CPU. [1]

See job003701 for the same issue wrt MVSpanAlloc.
AnalysisMVAlloc() [3] is spending a lot of time looping over spans, looking for a span with a "largest" block big enough for the allocation request. This is happening mostly to satisfy segment allocation for AMC.

When AMC recycles memory segments are destroyed and reallocated. This puts the burden of reallocating segment descriptors on the control pool, which is currently the MV pool.

What is most likely happening is that many spans are filled up with segment descriptors, and are left with a "largest" block, not big enough for another one. Many spans have to be searched before a free span is found. This has a bad complexity.

However this problem is exaggerated by the tiny value of extend-by used for the control pool.

From config.h [2].

/* Value of MPS_KEY_EXTEND_BY for the arena control pool.
Deliberately smaller than the default, because we don't expect the control
pool to be very heavily used. */
#define CONTROL_EXTEND_BY 4096

DL thinks this dates from the very beginnings of the MPS when segments descriptors were in a table in the arena instead of the tract table. Clearly the control pool is now heavily used.

Changing this to for example to (Size)65536 clears up the immediate problem, but leaves us with a potential scalability issue.


2. Use a more scalable pool for the control pool.
3. Improve the complexity of MV.
How foundmanual_test
Evidence[1] "Profiling CET" <>
[2] config.h <>
[3] poolmv.c <>
Created byDavid Lovemore
Created on2014-05-19 11:52:07
Last modified byDavid Lovemore
Last modified on2014-07-04 15:30:13
History2014-05-19 DL Created


Change Effect Date User Description
186832 closed 2014-07-04 15:27:48 David Lovemore        Set CONTROL_EXTEND_BY to 32768.
The CONTROL_EXTEND_BY value for the extend by on the control pool was set really small (4096) on the assumption that the control pool was not heavily used. However, since we allocate Seg's in the control pool and recycle them frequently, this assumption is no longer true.