[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg --smallmem has a larger footprint than --largemem

I placed a breakpoint in main/main.c, right near the end, so that I could
track memory footprint.  In smallmem mode, I see 1.3m more of data.  Here is

* dpkg loops thru all .list files, in both modes, and reads each .list into a
  new, non-freeing buffer.
* in largemem mode:
  * each full pathname is added to a hash, and a pointer is saved that points
    into the above non-freeing buffer.
* in smallmem mode:
  * each pathname is split into components.  These components are then built
    into a tree structure in memory.
  * For a directory component, a new non-freeing buffer is allocated, and
    the component is 'copied' into it.
  * For final name components, a reference is maintained into the above
    non-freeing buffer, or, if the flag fnn_nocopy is set, a new reference is
    created in a private chunk of memory(which is allocated 256k at a time).
* In all cases, the original .list block is not freed.

I've fixed the above problem, so that the .list is freed in low-mem mode, and,
unsurprisingly, there was no difference between largemem and smallmem
mode(Jason Gunthorpe has said that in his apt-inst, the loaded data footprint
is the same as the on disk size of .list, and he builds a tree structure).

So, in summary, dpkg will detect that it is on a low memory system, but end up
using more memory(this amount is equal to du *.list).

I have not retroactively checked dpkg cvs, to see if this was broken at some
point, but currently, --smallmem is hurtfull.

Version: 3.12
GCS d- s: a-- c+++ UL++++ P+ L++++ !E W+ M o+ K- W--- !O M- !V PS--
PE++ Y+ PGP++ t* 5++ X+ tv b+ D++ G e h*! !r z?
Adam Heath <doogie@debian.org>        Finger Print | KeyID
67 01 42 93 CA 37 FB 1E    63 C9 80 1D 08 CF 84 0A | DE656B05 PGP
AD46 C888 F587 F8A3 A6DA  3261 8A2C 7DC2 8BD4 A489 | 8BD4A489 GPG
-----END PGP INFO-----

Reply to: