On Tue, 11 Jul 2000, Tom Lane wrote:
> A straightforward solution would be to scan the entire freelist
> and give back the smallest block that's big enough for the request.
> That could be pretty slow (and induce lots of swap thrashing) so
> I don't like it much.
Yes. It is right solution. A little better chunk selection can be allowed
with more freelist than current 8. If we will 16 free lists a chunk real
size and request size will more similar.
> Another idea is to split the returned chunk and put the wasted part back
> as a smaller free chunk, but I don't think this solves the problem; it
> just means that the wasted space ends up on a small-chunk freelist, not
> that you can actually do anything with it. But maybe someone can figure
> out a variant that works better.
If I good understand it is a little like my idea with one-free-chunk from
block residual space.
It is not bad idea, but we have aligned chunks now. A question is if in
wasted part will always space for new *aligned* chunk. And second question,
not will this method create small and smaller chunks? For example you
after 1000 free/alloc you will have very much small chunks (from the wasted
part).
The chunk from wasted part is good, but you must have usage of this chunks.
*IMHO* current new mem design create new demand on context. In old design
we used one context for more different proccess and request-allocation-size
was more heterogeneous. But now, we use for specific operetions specific
contexts and it probably very often create context that use very homogeneous
chunks. For example if a testing my query cache 90% of all alocation are in
the range 16-32b and one cached plan need 2000-5000b --- effect it that
query cache not need 8Kb blocks ...etc. Very simular situation will in
other parts in PG.Tom add to AllocSet context defaul/max block size setting for each context.
It is good and it is first step to more specific context setting. Hmm,
I haven't idea for some next step now... But something setting is needful
for chunks operations (for example primary-default chunk size and from this
frequent freelist, big chunk limit setting ..etc.)
Karel
