<html><body>
<p><font size="2" face="sans-serif">Jason,</font><br>
<br>
<font size="2" face="sans-serif">Thank you for taking the time to reply to my note! A few data points and some questions...</font><br>
<br>
<font size="2" face="sans-serif">1. We did indeed verify that we have the same fragmentation outcome when running with narenas:1, suggesting that your second possibility was not the cause.  </font><br>
<br>
<font size="2" face="sans-serif">2. You suggested that this is likely because we have not yet reached the high water mark for our application. This is true, as the scenario I'm describing happens during the "preload phase" of the user's run. In this situation, the user is attempting to allocate 10g of data and the "eviction" thread is moving data from memory to disk until the user's load has completed. The goal of our application is to enforce a strict upper bound on user allocations and use eviction threads to enforce that boundary.</font><br>
<br>
<font size="2" face="sans-serif">3. For user loads which use object sizes greater than the page size (4k), we have not observed the same type of internal fragmentation when the eviction threads start firing. Is this problem somehow specific to the small bins? If so, why would that be?</font><br>
<br>
<font size="2" face="sans-serif">4. Our assumption was that the holes left in memory due to the eviction thread would be available for the further "insert" threads to leverage. Is this not what's happening?</font><br>
<br>
<font size="2" face="sans-serif">5.  Maybe we could place "evictable" data objects into specific chunks. At our application level, do we have any efficient introspection that we can do to gain insight into which chunks different objs end up living? </font><br>
<br>
<font size="2" face="sans-serif">Thanks,</font><br>
<font size="2" face="sans-serif">Thom</font><br>
<br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Jason Evans ---05/07/2013 05:10:33 PM---On May 7, 2013, at 1:16 PM, Thomas W Savage wrote: > My team "><font size="2" color="#424282" face="sans-serif">Jason Evans ---05/07/2013 05:10:33 PM---On May 7, 2013, at 1:16 PM, Thomas W Savage wrote: > My team is having trouble determining how to ad</font><br>
<br>

<table width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>

<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">From:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">Jason Evans <jasone@canonware.com></font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>

<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">To:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">Thomas W Savage/Durham/IBM@IBMUS, </font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>

<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Cc:</font></ul>
</td><td width="100%" valign="middle"><img width="1" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">jemalloc-discuss@canonware.com</font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>

<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Date:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">05/07/2013 05:10 PM</font></td></tr>

<tr valign="top"><td width="1%"><img width="96" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>

<ul style="padding-left: 4pt"><font size="1" color="#5F5F5F" face="sans-serif">Subject:</font></ul>
</td><td width="100%"><img width="1" height="1" src="cid:2__=0ABBF1F6DFF4DFAA8f9e8a93df938@us.ibm.com" border="0" alt=""><br>
<font size="1" face="sans-serif">Re: Workload causes significant internal fragmentation</font></td></tr>
</table>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="3" face="serif">On May 7, 2013, at 1:16 PM, Thomas W Savage wrote:</font>
<ul style="padding-left: 36pt"><br>
<font size="2" face="sans-serif">My team is having trouble determining how to address increasing internal fragmentation (sizeable diff b/w Jm allocated and active) for a particular workload. </font><font size="3" face="serif"><br>
</font><font size="2" face="sans-serif"><br>
We are allocating objects into three small bins (48, 320, 896). We start with an insertion phase in which we continually allocate "entries", which are made up of four allocations: 2x 48-byte objects, 1x 320 obj, and 1x 896 obj. Once we have inserted entries up to a certain threshold, we begin an eviction phase in which we have some threads continuing insertion and another thread freeing 320's and 896's (not touching the 48's). By the end of this run, we observe significant internal fragmentation as demonstrated in the stats below. Is there anything that can be done to mitigate this internal frag?</font><font size="3" face="serif"><br>
</font><tt><font size="1"><br>
Version: 3.3.1-0-g9ef9d9e8c271cdf14f664b871a8f98c827714784<br>
Assertions disabled<br>
Run-time option settings:<br>
  opt.abort: false<br>
  opt.lg_chunk: 21<br>
  opt.dss: "secondary"<br>
  opt.narenas: 96<br>
  opt.lg_dirty_mult: 1<br>
  opt.stats_print: false<br>
  opt.junk: false<br>
  opt.quarantine: 0<br>
  opt.redzone: false<br>
  opt.zero: false<br>
CPUs: 24<br>
Arenas: 96<br>
Pointer size: 8<br>
Quantum size: 16<br>
Page size: 4096<br>
Min active:dirty page ratio per arena: 2:1<br>
Chunk size: 2097152 (2ˆ21)<br>
Allocated: 7574200736, active: 8860864512, mapped: 9013559296<br>
Current active ceiling: 8963227648<br>
chunks: nchunks   highchunks    curchunks<br>
           4553         4298         4298<br>
huge: nmalloc      ndalloc    allocated<br>
           16           15     35651584<br>
<br>
Merged arenas stats:<br>
assigned threads: 79<br>
dss allocation precedence: N/A<br>
dirty pages: 2154593:0 active:dirty, 0 sweeps, 0 madvises, 0 purged<br>
            allocated      nmalloc      ndalloc    nrequests<br>
small:     7515054496     29540988      3552884     29540988<br>
large:       23494656         1432            0         1432<br>
total:     7538549152     29542420      3552884     29542420<br>
active:    8825212928<br>
mapped:    8973713408<br>
bins:     bin  size regs pgs    allocated      nmalloc      ndalloc      newruns       reruns      curruns<br>
            0     8  501   1          176           22            0           11            0           11<br>
[1]<br>
            2    32  126   1        68448         2187           48           22            0           21<br>
            3    48   84   1         13880077            0       165272            0       165272<br>
[4]<br>
            5    80   50   1         1760           22            0           11            0           11<br>
            6    96   84   2         2112           22            0           11            0           11<br>
[7..12]<br>
           13   320   63   5   2221154560      8717502      1776394       125156       701794       125156<br>
[14..18]<br>
           19   896   45  10   4627583744      6941156      1776442       135776       692084       135774<br>
[20..27]<br>
large:   size pages      nmalloc      ndalloc    nrequests      curruns<br>
[1]<br>
         8192     2           22            0           22           22<br>
[1]<br>
        16384     4         1408            0         1408         1408<br>
[13]<br>
        73728    18            1            0            1            1<br>
[23]<br>
       172032    42            1            0            1            1<br>
[467]<br>
--- End jemalloc statistics --- </font></tt></ul>
<br>
<font size="3" face="serif">The external fragmentation for 320- and 896-byte region runs is 12% and 15%, respectively.  First off, that doesn't strike me as terrible, depending on the details of what's going on in the application.  There are two possible explanations (not mutually exclusive): 1) the application's memory usage is not at the high water mark, and 2) the eviction thread does not evict in a pattern that impacts the allocating threads proportionally to their allocation volumes.  Say that there are two arenas, and 75% of the evictions are objects allocated from arena 0, but arenas 0 and 1 are utilized equally by the allocating threads.  The result will be substantial arena 0 external fragmentation in the equilibrium state.  You can figure out whether (2) is a factor by running with one arena (which will surely impact performance, since you have thread caching disabled).  If fragmentation remains the same with one arena, then (1) is the entire explanation.</font><br>
<br>
<font size="3" face="serif">One possible solution that should be allocator-agnostic would be to interleave eviction with normal allocation in all threads, such that threads evict their own previous allocations at a rate proportional to their allocation rates.  This changes the global eviction policy to one that is distributed though, so it may not be appropriate, depending on what your application does.</font><br>
<br>
<font size="3" face="serif">Jason</font><br>
<br>
</body></html>