Date: Fri, 30 May 2025 09:02:50 -0700 From: Mark Millard <marklmi@yahoo.com> To: Graham Perrin <grahamperrin@gmail.com>, FreeBSD-pkg@freebsd.org Cc: FreeBSD-pkgbase@freebsd.org Subject: Re: CFT: pkgbase support in 15.0 Message-ID: <D2C64F39-B6EA-47BD-B88E-B4D729BE0150@yahoo.com> References: <D2C64F39-B6EA-47BD-B88E-B4D729BE0150.ref@yahoo.com>
index | next in thread | previous in thread | raw e-mail
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.comhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D2C64F39-B6EA-47BD-B88E-B4D729BE0150>