Re: NetBSD and ECC RAM?

[Kevin Bowling]

On Mon, Feb 19, 2024 at 12:19 AM Michael van Elst  wrote:
>
> michael.chepo...@gmail.com (Michael Cheponis) writes:
>
> >I've been running ECC in the Windows box for years, it seems like a 'no
> >brainer' for servers. Servers usually run for years, and Stuff Happens over
> >the years [1].
> >But I'd prefer a reliable, unhackable, trustable compute fabric.  ECC is
> >part of the 'reliable' part.
>
> I agree, but the "box" will run with ECC, even when the OS doesn't
> know about it. OS support is needed to get information about errors
> and for better fault tolerance.

Servers tend to have BMCs, so you can execute 'ipmitool sensors' and
'ipmi sel elist' to get the information out.

Linux has the 'EDAC' subsystem but I don't think it gains you so much
if you have a BMC.  Kernel printfs for some errors and character
drivers to do userspace development.  And it would support systems
without BMCs.  A lot of fragile chipset specific code to get that.

>
> >I would also like to see per /dev entry ACLs.  I would like to see better
> >security than owner-group-everbody permissions.
>
> I have rarely seen ACLs being used for "better security". Even when that
> was possible, the complexity usually outweighed any gain in control.
>
> Systems that implied access control through simple rules worked much
> better. It's still not a feature that you had to enable or a switch
> you toggled, it requires constant effort, in particular on systems
> that don't just perform a fixed set of functions.
>

Re: top(1) behavior

[Kevin Bowling]

On Fri, Aug 11, 2023 at 11:25 PM Martin Husemann  wrote:
>
> On Fri, Aug 11, 2023 at 07:04:01PM -0700, Kevin Bowling wrote:
> > A real example is doing a -j 8 kernel build.  Up in the top of top(1),
> > I see global CPU usage in the high 90%.  Down in the process list, I
> > see a few processes in the 1-10% range that do not add up to 800%.  I
> > see some of the cc1 processes with 0% WCPU%/CPU%.
>
> I am not sure I see what you mean, for me typically there are a few gcc
> processes that take all the cpu, or later (close to the end) a few
> xz or gzip processes. At a few spots ld wins and hogs at least one cpu
> completely.
>
> At least it looks not completely off, the top area displays statistics for
> aggregated intervals, while many processes (besides the ones mentioned)
> are very short lived - so the display is mostly what I'd expect it to be.
>
> If you do "top -b" (so the list is not truncated) and save it to a file,
> do you get a snapshot that is still unreasonable from your POV? Can you
> share a concrete example?

Here's a sample, this one is a bit better since the cc1plus processes
stick around for a bit longer but it still shows the WCPU% not adding
up near the global CPU stats.  I can annotate it as an image if it is
still not clear.

load averages:  6.15,  3.21,  1.67;   up 0+04:56:56
12:37:26
142 threads: 2 runnable, 123 sleeping, 10 zombie, 7 on CPU
CPU0 states: 92.6% user,  0.0% nice,  7.4% system,  0.0% interrupt,  0.0% idle
CPU1 states: 91.6% user,  0.0% nice,  8.2% system,  0.0% interrupt,  0.2% idle
CPU2 states: 91.6% user,  0.0% nice,  8.4% system,  0.0% interrupt,  0.0% idle
CPU3 states: 89.4% user,  0.0% nice, 10.0% system,  0.0% interrupt,  0.6% idle
CPU4 states: 57.9% user,  0.0% nice, 10.2% system,  0.0% interrupt, 31.9% idle
CPU5 states: 99.8% user,  0.0% nice,  0.2% system,  0.0% interrupt,  0.0% idle
CPU6 states: 96.2% user,  0.0% nice,  3.4% system,  0.0% interrupt,  0.4% idle
CPU7 states: 97.0% user,  0.0% nice,  3.0% system,  0.0% interrupt,  0.0% idle
Memory: 7213M Act, 5392K Inact, 110M Wired, 105M Exec, 5933M File, 7165M Free
Swap: 16G Total, 16G Free / Pools: 1017M Used

 PID   LID USERNAME PRI STATE   TIME   WCPUCPU NAME  COMMAND
1598  1598 kev00925 CPU/5   0:26 98.03% 72.66% - cc1plus
6906  6906 kev00925 CPU/7   0:26 96.51% 71.53% - cc1plus
29633 29633 kev00925 CPU/2   0:01 64.58%  6.15% - cc1plus
6016  6016 kev00925 CPU/6   0:01 75.00%  3.66% - cc1plus
5636  5636 kev00925 CPU/1   0:01 50.00%  2.44% - cc1plus
2855  2855 kev00985 poll/1  1:14  0.59%  0.59% - xfce4-terminal
1867  1867 kev00985 poll/3  2:00  0.00%  0.00% - X
2041  2041 kev00985 poll/0  0:19  0.00%  0.00% - xfwm4
1867  1629 kev00985 poll/3  0:14  0.00%  0.00% - X
2016  2016 kev00985 poll/7  0:07  0.00%  0.00% - xfce4-panel
2099  2099 kev00985 poll/1  0:03  0.00%  0.00% - xfdesktop
2239  2239 kev00985 select/00:02  0.00%  0.00% - xscreensaver
 598   598 root  85 poll/2  0:01  0.00%  0.00% - dhcpcd
 599   599 _dhcpcd   85 poll/3  0:01  0.00%  0.00% - dhcpcd
2016  2089 kev00985 poll/0  0:01  0.00%  0.00% gmain xfce4-panel
 774   774 kev00985 poll/0  0:01  0.00%  0.00% - gvfsd-trash
18154 18154 kev00943 CPU/3   0:00  0.00%  0.00% - top
3737  3737 kev00925 CPU/0   0:00  0.00%  0.00% - cc1plus
15778 15778 kev00925 RUN/3   0:00  0.00%  0.00% - cc1plus
9044  9044 kev00925 RUN/3   0:00  0.00%  0.00% - cc1plus
3365  3365 kev00986 wait/0  0:00  0.00%  0.00% - su
   1 1 root  85 wait/3  0:00  0.00%  0.00% - init
23460 23460 kev00985 poll/1  0:00  0.00%  0.00% - nbmake
1402  1402 kev00985 poll/2  0:00  0.00%  0.00% - nbmake
19515 19515 kev00985 ttyraw/00:00  0.00%  0.00% - sh
 545   545 kev00985 poll/6  0:00  0.00%  0.00% - thunar
2016  2087 kev00985 poll/1  0:00  0.00%  0.00% gdbus xfce4-panel
2044  2205 kev00985 poll/2  0:00  0.00%  0.00% gdbus xfsettingsd
2044  2019 kev00985 poll/2  0:00  0.00%  0.00% gmain xfsettingsd
2044  2044 kev00985 poll/2  0:00  0.00%  0.00% - xfsettingsd
2041  2267 kev00985 poll/7  0:00  0.00%  0.00% gdbus xfwm4
2041  1886 kev00985 poll/5  0:00  0.00%  0.00% gmain xfwm4
2036  2036 kev00985 poll/3  0:00  0.00%  0.00% - ssh-agent
1617  2037 kev00985 poll/4  0:00  0.00%  0.00% gdbus
at-spi2-registry
1617  2021 kev00985 poll/6  0:00  0.00%  0.00% gmain
at-spi2-registry
1617  1617 kev00985 poll/1  0:00  0.00%  0.

Re: top(1) behavior

[Kevin Bowling]

On Fri, Aug 11, 2023 at 2:01 AM Martin Husemann  wrote:
>
> On Thu, Aug 10, 2023 at 02:13:12PM -0700, Kevin Bowling wrote:
> > When running something heavy yet ephemeral like a parallel make, I can
> > see expected CPU usage in the summary or per-cpu view.  However, I
> > rarely see the process(es) consuming the CPU momentarily during the
> > update intervals reflected accordingly in the per process view below.
> > I find the behavior somewhat surprising compared to FreeBSD top(1) and
> > am wondering what the difference is.
>
> You mean you often don't see the process with STATE CPU/0 (or some other
> cpu)?

Hi Martin,

A real example is doing a -j 8 kernel build.  Up in the top of top(1),
I see global CPU usage in the high 90%.  Down in the process list, I
see a few processes in the 1-10% range that do not add up to 800%.  I
see some of the cc1 processes with 0% WCPU%/CPU%.

> Maybe FreeBSD uses a different default sort - you could try experimenting
> if you get similar display with something like "top -o ..." and various
> sort fields.

I checked these fields out, sorting by cpu for instance and see the same deal.

I checked FreeBSD and Linux and they don't get it perfect.. the former
seems to have slightly better accounting of momentary processes down
in the process list somehow though.

> Martin

top(1) behavior

[Kevin Bowling]

Hi,

I am somewhat new to NetBSD and am curious about the behavior of top(1).

When running something heavy yet ephemeral like a parallel make, I can
see expected CPU usage in the summary or per-cpu view.  However, I
rarely see the process(es) consuming the CPU momentarily during the
update intervals reflected accordingly in the per process view below.
I find the behavior somewhat surprising compared to FreeBSD top(1) and
am wondering what the difference is.

Regards,
Kevin