[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-arm
Subject:    Re: random process crashes on RPI3 and RPI4
From:       Jan Stary <hans () stare ! cz>
Date:       2021-11-06 14:57:45
Message-ID: YYaX6cFftRevyJ/d () www ! stare ! cz
[Download RAW message or body]

On Nov 06 11:35:52, kolipe.c@exoticsilicon.com wrote:
> > > Also worth noting is that it depends on what the process is doing.
> > > I've run invocations of md5 -tt on all cores, loading the CPU 100%
> > > for several hours and not seen a crash.  Yet a kernel compile fails
> > > within minutes.  Presumably it's because the compiler is manipulating
> > > a large number of pointers, and quickly tries to make an invalid
> > > memory access.
> > 
> > I don't know what you mean by that. If a compiler (or any other process
> > for that matter) "makes an invalid memory access", it should be killed,
> > regardless of whether swap space exists or not.
> 
> What I mean is that if the process memory space is being corrupted, or
> otherwise returning bad data on reads, then I would expect the md5
> processes to continue running, but produce occasional bad hashes.

But as you said, that is not the case.

> I would expect the compiler to fail due to a segmentation fault,

That's also not the case, at least here. A segfault is reported as such,
my process crashes were not. The console just said 'Killed'.

So I doubt it's either reading the wrong pages or causing segfaults;
but needles to say, kernel VM code is way above my head.

> > > and with certain workloads may give better performance.
> > > For example, a large operation on a database
> > > generating temporary data in RAM that will not be used immediately
> > 
> > What would be an example of such an operation?
> 
> Imagine a 3D graphics rendering program that calculates vectors and other
> data for a number of objects in a large scene.  Some of the objects are
> hidden from view by other objects or not rendered because they are not
> within the current scene.
> 
> The program doesn't necessarily know which of those vectors and other
> associated data that have been calculated might be used as the viewpoint
> changes, or when they might be needed, (seconds later, minutes later,
> hours later, or never).  The data is worth keeping available, to avoid
> the need to re-calculate it later, but keeping it in physical RAM would
> mean that another process wanting to allocate and use a large amount of
> memory for a short period of time would have to first wait for the
> graphics data to be swapped out.
> 
> It's clear to see that memory which has been written but not read back
> for a period of time is a good candidate to write to swap.

I don't necessarily believe that; e.g. time(1) will save the timestamp
and run for hours, only to read that timestamp back when calculating
the time elapsed. Why would you swap that?

> If the
> data is then requested immediately after having written it to swap,
> there is no need to read it back from disk, as the data in physical RAM
> has not been overwritten.

The whole premise was that you swap it out so that the memory
can be offered to other processes. So it might have been overwritten,
which was the whole point.

Unless "immediately" means the very next instruction
by the same process, in which case there was no point swapping it.

But I didn't mean to get into a discussion of swapping.
What puzzles me is that swap is used and needed, apparently,
even if there is plenty of RAM to be used. So far, I assumed
(naively) that swap was only used when you ran out of memory.

	Jan

[prev in list] [next in list] [prev in thread] [next in thread]