Re: warn-maybe-out-of-memory

[Stefan Monnier]

> AFAICS on Linux, this is not true - in my tests, huge allocations
> may be 20% slower when the kernel should reclaim cache space first.

20% slower is still pretty damn fast compared to the time Emacs will
take to fill that space, so it's really not a reason to take this
measurement into account.

>> The OS wants to keep as much stuff in the cache as it can, thus
>> minimizing the "free" space, since "free" here basically means "wasted".
> This depends on usage patterns.  If you interleave I/O and relatively
> large allocations, it's fairly unreasonable to fill almost all memory
> with cached data just to throw it away very soon.

No, the OS doesn't actively fill the memory with cache data.  It just
waits to throw it away as late as possible.

>> If your "free" includes "free in RAM + free in swap" then it's
>> marginally more useful ("free in RAM" will usually be close to 0,
>> whereas "free in swap" should usually be fairly large), but I still
>> can't think of a frequent enough configuration and situation where this
>> would be useful enough to justify wasting code on it.
> This is not expected to be frequent.

I'm not just talking about "infrequent".  Currently, I can't think of
a single case where this would be useful given the existence of
large-file-threshold.


        Stefan