Re: 2.4.16 memory badness (reproducible)

[Leigh Orf <orf@mailbag.com>]

More clues...

The only way I can seem to bring the machine back to being totally
normal after buff/cache fullness is to force some swap to be written,
such as by doing

lmdd opat=1 count=1 bs=900m

If I do

lmdd opat=1 count=1 bs=500m

about 500MB of memory is freed but no swap is written, and modify_ldt
still returns ENOMEM if I run xmms, display, etc....

It looks like the problem is somewhere in vmalloc since that's what
returns a null pointer where ENOMEM gets set in arch/i386/kernel/ldt.c

BTW I have been running kernels with

CONFIG_HIGHMEM4G=y
CONFIG_HIGHMEM=y

I am compiling a kernel with

CONFIG_NOHIGHMEM=y

and will see if the bad memory behavior continues.

Leigh Orf

Leigh Orf wrote:

|   I've noticed a couple more things with the memory allocation
|   problem with large buffer and cache allocation. Some
|   applications will fail with ENOMEM *even if* there is a
|   considerable amount (say, 62 MB as below) of "truly" free
|   memory.
|
|   The second thing I've noticed is that all these apps that die
|   with ENOMEM pretty much have the same strace output towards
|   the end. What is strange is "display *.tif" dies while "ee
|   *.tif" and "gimp *.tif" does not. Piping the strace output of
|   commands that *don't* cause this behavior and grepping for
|   modify_ldt shows that modify_ldt is *not* being called for
|   apps that *don't* die.
|
|   So I don't know if it's a symptom or a cause, but modify_ldt
|   seems to be triggering the problem. Not being a kernel
|   hacker, I leave the analysis of this to those who are.
|
|   Leigh Orf