New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange behaviour of small allocator #5216
Comments
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 12, 2020
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 12, 2020
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 12, 2020
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 12, 2020
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 12, 2020
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 13, 2020
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 13, 2020
Change box/cfg test. Previously, if we set slab_alloc_factor > 2, the small_alloc_create function quietly changed it to 2, now I add assert slab_alloc_factor > 1.0 && slab_alloc_factor <= 2. Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 13, 2020
Change box/cfg test. Previously, if we set slab_alloc_factor > 2, the small_alloc_create function quietly changed it to 2, now I add assert slab_alloc_factor > 1.0 && slab_alloc_factor <= 2. Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Nov 13, 2020
Add a check that the slab_alloc_factor is in the range (1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 7, 2020
Add a check that the slab_alloc_factor is in the range (1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 10, 2020
Add a check that the slab_alloc_factor is in the range (1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 10, 2020
Add a check that the slab_alloc_factor is in the range (1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 17, 2020
Add a check that the slab_alloc_factor is in the range (1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 17, 2020
Add a check that the slab_alloc_factor is in the range (1.0, 2.0] and if it is not so changed it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 21, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 22, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 23, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 24, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 24, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 24, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 24, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 24, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 25, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 25, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 28, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 29, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
kyukhin
pushed a commit
that referenced
this issue
Dec 29, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
EvgenyMekhanik
added a commit
that referenced
this issue
Dec 29, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
kyukhin
pushed a commit
that referenced
this issue
Dec 29, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216 (cherry picked from commit 4d175bf)
kyukhin
pushed a commit
that referenced
this issue
Dec 29, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216 (cherry picked from commit 4d175bf)
kyukhin
pushed a commit
that referenced
this issue
Dec 29, 2020
Previously, in small allocator, memory pools were allocated at the request, which in the case of a small slab_alloc_factor led to use pools with incorrect sizes. This patch changed small allocator behavior, now we allocate pools on the stage of allocator creation. Also we use special function to find appropriate pool, which is faster, then previous version with rbtree. This change fixes #5216. Also moved a check, that the slab_alloc_factor is in the range (1.0, 2.0] from small allocator to memtx_engine. If factor is not in range change it to 1.0001 or 2.0 respectively Closes #5216
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tarantool version: any
The code
breaks debug version of tarantool:
and puts release version to unexpected state (see mem_used):
The text was updated successfully, but these errors were encountered: