Re: PATCH: two slab-like memory allocators
От | Michael Paquier |
---|---|
Тема | Re: PATCH: two slab-like memory allocators |
Дата | |
Msg-id | CAB7nPqRSeXqEFXtvrivVMfmvjSapkKR=1xvY80OkuhP+a9TGSQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: PATCH: two slab-like memory allocators (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
On Sun, Oct 2, 2016 at 10:15 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > One more comment about GenSlab, particularly about unpredictability of the > repalloc() behavior. It works for "large" chunks allocated in the AllocSet > part, and mostly does not work for "small" chunks allocated in the > SlabContext. Moreover, the chunkSize changes over time, so for two chunks of > the same size, repalloc() may work on one of them and fail on the other, > depending on time of allocation. > > With SlabContext it's perfectly predictable - repalloc() call fails unless > the chunk size is exactly the same as before (which is perhaps a bit > pointless, but if we decide to fail even in this case it'll work 100% time). > > But with GenSlabContext it's unclear whether the call fails or not. > > I don't like this unpredictability - I'd much rather have consistent > failures (making sure people don't do repalloc() on with GenSlab). But I > don't see a nice way to achieve that - the repalloc() call does not go > through GenSlabRealloc() at all, but directly to SlabRealloc() or > AllocSetRealloc(). > > The best solution I can think of is adding an alternate version of > AllocSetMethods, pointing to a different AllocSetReset implementation. You guys are still playing with this patch, so moved to next CF with "waiting on author". -- Michael
В списке pgsql-hackers по дате отправления: