On 8/28/19 11:48 AM, vincentfu@xxxxxxxxx wrote: > From: Vincent Fu <vincent.fu@xxxxxxx> > > If one process is making smalloc calls and another process is making > sfree calls, pool->free_blocks and pool->next_non_full will not be > synchronized because the two processes each have independent, local > copies of the variables. > > This patch allocates space for the two variables from shared storage so > that separate processes will be modifying quantities stored at the same > locations. > > This issue was discovered on the server side running a client/server job > with --status-interval=1. Such a job encountered an OOM error when only > ~50 objects were allocated from the smalloc pool. > > Also change the calculation of free_blocks in add_pool() to use > SMALLOC_BPI instead of SMALLOC_BPB. These two constants are > coincidentally the same on Linux and Windows but SMALLOC_BPI is the > correct one to use. free_blocks is the number of available blocks of > size SMALLOC_BPB. It is the product of the number of unsigned integers > in the bitmap (bitmap_blocks) and the number of bits per unsigned > integer (SMALLOC_BPI). Would it make more sense to just have the pool[] come out of shared memory? -- Jens Axboe
