Re: ulimit -d/-m do not actually work

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 23 Oct 2024 19:27:31 +0200
    From:        Michael van Elst <mlelstv%serpens.de@localhost>
    Message-ID:  <ZxkyA7WfRPKPYhaZ%serpens.de@localhost>

  | The three categories no longer match the real world when people started
  | to use shared memory, and you can not pretend that these are still
  | sufficient as a model.

I can pretend almost anything - but I don't really need to here.   Things
only don't match if you are trying to make the limit match a particular
implementation model - if you simply count the data segment as all memory
allocated read-write, except the stack, etc, the concepts are simple.

Shared memory is irrelevant, the limit is upon how much this process has
allocated in its address space, how much of that might be shared with some
other process is irrelevant - this isn't doing some kind of sharing, or
billing, accounting, where something shared needs to have its cost
apportioned amongst all the users, it is a simple limit upon how much
one process may access.

  | But more important, the limits are also no longer fit for their purpose.
  | What does a memory limit mean, when you can still allocate address space

That clearly would be a bug, the whole point of the limit is to
prevent more address space being allocated (without releasing
something else first).

  | and what does an address space limit mean, when it doesn't affect
  | memory usage ?

It controls how big the process can be.   How much of it is resident
in RAM depends upon competing requests, and how much RAM is available
in the first place, and is an entirely different question.

This really all ought to be very simple.

kre