Re: Git and buildworld running at the same time

On Sep 14, 2025, at 14:29, Mark Millard <marklmi@yahoo.com> wrote:

> bob prohaska <fbsd_at_www.zefox.net> wrote on
> Date: Sun, 14 Sep 2025 16:37:03 UTC :
>> 
>> On Sun, Sep 14, 2025 at 09:25:33AM -0700, bob prohaska wrote:
>>> 
>>> Top does not show any flags applied to git, and a
>>> ps -aux | grep git
>>> reports only the "grep git" process, nothing else.
>> 
>> This claim now seems wrong. A repeat of ps -aux reports:
>> 
>> root@www:/usr/src # ps -aux | grep git
>> root 9398 8.9 80.5 1346480 768984 - R 09:07 8:34.59 /usr/local/libexec/git-core/git pack-objects --local --delta-base-of
>> root 9396 0.0 0.1 9132 860 - Is 09:07 0:00.01 /usr/local/libexec/git-core/git gc --auto --no-quiet
>> root 9397 0.0 0.1 9100 868 - I 09:07 0:00.05 /usr/local/libexec/git-core/git repack -d -l -A --unpack-unreachable
>> root 9499 0.0 0.2 4800 1688 1 S+ 09:29 0:00.02 grep git
>> [lines are wrapped]
>> 
>> So, git definitely returns a shell prompt before it's finished working.
>> At the moment git occupies 1.3 GB RAM, 505 MB swap and 10-15% CPU.

The above "1.3 GB RAM" seems odd for a RPi2B with
only 1 GiByte of RAM. The ps columns are:

USER    PID   %CPU %MEM   VSZ   RSS TT  STAT STARTED        TIME COMMAND

RSS is a RAM usage figure (768984); VSZ is Virtual
SiZe (1346480). VSZ can be bigger than RAM+SWAP for
the process, as I understand. (Making simple
arithmetic problematical.)

Was the "505 MB" system level swap usage, instead
of process specific swap usage?

> If I gather correctly, it looks like at times, when it
> will be a notable time before activity like building
> software, something like:
> 
> git -C /usr/src/ gc --no-detach --auto
> 
> would be appropriate. The "--no-detach" avoids it
> running in the background so you know when it is
> running vs. when it finishes. You would want to do
> this often enough to avoid fetch/merge --ff-only
> or pull from doing such automatically or having
> a lot of accumulated pending work to do.
> 
> There is:
> 
>     gc.autoDetach
>         Make git gc --auto return immediately and run in the background if
>         the system supports it. Default is true. This config variable acts as
>         a fallback in case maintenance.autoDetach is not set.
> 
> and also:
> 
>     maintenance.autoDetach
>         Many Git commands trigger automatic maintenance after they have
>         written data into the repository. This boolean config option controls
>         whether this automatic maintenance shall happen in the foreground or
>         whether the maintenance process shall detach and continue to run in
>         the background.
> 
>         If unset, the value of gc.autoDetach is used as a fallback. Defaults
>         to true if both are unset, meaning that the maintenance process will
>         detach.
> 
> So you can force it to not detach automatically.
> But, then, you might have a long wait for the
> command that added data to complete:
> 
> # git -C /usr/src/ config maintenance.autoDetach false
> # git -C /usr/src/ config          gc.autoDetach false
> 


===
Mark Millard
marklmi at yahoo.com