| Title | MVAlloc taking significant CPU in profiles |
| Status | closed |
| Priority | optional |
| Assigned user | David Lovemore |
| Organization | Ravenbrook |
| Description | MVAlloc shows up in profiles of CET, as taking around 5% of CPU. [1] See job003701 for the same issue wrt MVSpanAlloc. |
| Analysis | MVAlloc() [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. Solutions: 1. Fix CONTROL_EXTEND_BY 2. Use a more scalable pool for the control pool. 3. Improve the complexity of MV. |
| How found | manual_test |
| Evidence | [1] "Profiling CET" <https://info.ravenbrook.com/mail/2014/02/10/14-43-29/0/>[2] config.h < https://info.ravenbrook.com/project/mps/master/code/config.h>[3] poolmv.c < https://info.ravenbrook.com/project/mps/master/code/poolmv.c> |
| Created by | David Lovemore |
| Created on | 2014-05-19 11:52:07 |
| Last modified by | David Lovemore |
| Last modified on | 2014-07-04 15:30:13 |
| History | 2014-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. |