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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/