Re: CFT: pkgbase support in 15.0

Graham Perrin <grahamperrin_at_gmail.com> wrote on
Date: Fri, 30 May 2025 08:18:17 UTC :

[This seems to be about pkg in use for updating ports, but
was sent to just FreeBSD-pkgbase@ instead of to
FreeBSD-pkg@ .]

> Maybe worth noting:
> 
> 
> A) pkg: killed: failed to reclaim memory
> <https://www.reddit.com/r/freebsd/comments/1evetpj/comment/>

First, some notes about the various reports that were
not here for reference, various examples, including
notes about missing information:

4 GiBytes of RAM with 16 GByte of SWAP (ZFS? tmpfs use?)
(sddm-gre* and Xorg are shown to be in use in the screen
shot)

real memory = 536870912 (512 MB)
avail memory = 481169408 (458 MB)
(SWAP? ZFS? tmpfs use? sddm? Xorg?)

2048 MB "Base Memory". ZFS is shown as in use for this
example. (SWAP? tmpfs use?) (sddm? Xorg?)

In general for leading up to the failures:

All significant sources of keeping at least one CPU busy
keeping memory use active and free RAM low? (This
combination does NOT use SWAP for paging the Active
category's RAM use. "failed to reclaim memory" means
Active stayed large via busy CPUs and the FreeRAM
threshold was not achieved within vm.pageout_oom_seq
attempts.)

Note about the above: If SWAP avoids memory constraints
is workload dependent. It takes specifying workload
properties to identify if SWAP space for paging use is
helpful vs. not.

Active? Inact? Wired? Free? Swap? for use leading up to
the failure? Which processes were keeping the Active
category large via the memory access patterns of some
busy cpu(s)? (Note: Wired includes the ZFS ARC.)

Context for the following quote: Based on the same amount
of RAM, going from a 32-bit system to a 64-bit one does
not generally mean needing less RAM (or less RAM+SWAP):
they are separate issues. The Design and Implementation
of the FreeBSD Operating System 2nd edition, bottom
paragraph of page 49 and top paragraph of page 549, both
being sections about ZFS:

"However, it is neither designed for nor is it well suited
to run on resource-constrained systems using 32-bit CPUs
with less than 8 GBytes of memory and one small, nearly
full disk typical of many embedded system. Thus, the fast
filesystem continues to be the file system of choice for
these smaller systems."

(There is more material documenting the context for the
repeated summary statements.)

I expect that VM configurations made to look like such
a system count in that.

Did you do any tuning of the ZFS-in-use examples to try
to mitigate some of that status? (Not that I've any
expertise to interpret/judge such.)

You wrote elsewhere:

QUOTE
I might expect a killing in a constrained environment,
however in this case:
    • the virtual machine has 4 G memory (and 16 G swap)
. . .
END QUOTE

When ZFS is involved, your definition for constrained vs.
not does not match the Book's.

> B) pkg upgrade finding nothing after an incomplete upgrade
> <https://github.com/freebsd/pkg/issues/2441>, in particular
> <https://github.com/freebsd/pkg/issues/2441#issuecomment-2799590401>
> 
> > … I see what may be variations of this issue:
> |>
> > * pkg upgrade| following an interruption to an upgrade command
> />   does/ proceed to install packages, but not everything
> >   that should be installed.
> 
> 
> Scenario A is not rare.

For whatever the type of contexts you have set up, anyway.

> It may lead to scenario B.

Your types of contexts that are having the problem may well
be good as part of tests of some error-handling
and/or of some recovery-procedures.

> Whilst B (with or without A) might not affect a base package, affected 
> users might perceive the overall upgrade experience (including base) as 
> unreliable.


===
Mark Millard
marklmi at yahoo.com