Hi,
Yet another thing showed up (possible data corruption on x86-64), so here
goes -rc5.
Summary of changes from v2.4.23-rc4 to v2.4.23-rc5
============================================
Andi Kleen:
o Fix 32bit truncate64 on x86-64
Marcelo Tosatti:
o Felix Radensky: Remove debugging printk from agpgart
o Changed EXTRAVERSION to -rc5
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
It's not on kernel.org yet...
Did you forgot to upload it again? O:-)
Marcos Marado
- --
==================================================
Marcos Daniel Marado Torres AKA Mind Booster Noori
/"\ http://student.dei.uc.pt/~marado
\ / [email protected]
X ASCII Ribbon Campaign
/ \ against HTML e-mail and Micro$oft attachments
==================================================
On Tue, 25 Nov 2003, Marcelo Tosatti wrote:
>
>
> Hi,
>
> Yet another thing showed up (possible data corruption on x86-64), so here
> goes -rc5.
>
>
> Summary of changes from v2.4.23-rc4 to v2.4.23-rc5
> ============================================
>
> Andi Kleen:
> o Fix 32bit truncate64 on x86-64
>
> Marcelo Tosatti:
> o Felix Radensky: Remove debugging printk from agpgart
> o Changed EXTRAVERSION to -rc5
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQE/w1pOmNlq8m+oD34RAhE5AKCXsmUR1AM6Is76HSO6VxUma9O9TwCdFEvo
p11Y6XEbIxeVDUYTAB+xdXo=
=ggWy
-----END PGP SIGNATURE-----
Hi!
I was investigating memory allocation problems on my systems.
And I only figured out that I'm using quite up-to-date kernel - 2.4.22.
This is my post from another thread:
> Vanilla 2.4.22 (this is x86) (with HZ=1024, if it does matter).
>
> after '# echo -1 >/proc/sys/vm/overcommit_memory'
> 1. test app with memory touch still gets killed by
> oom_killer. (so no malloc() == NULL)
> 2. test app w/o memory touch still can happily allocate 2.8GB
> of memory (x86 - looks like 3/1 memory split) and only then
> gets NULL pointer - oom_killer is silent.
"overcommit_memory < 0" supposed to not allow apps to overallocate
memory - but still it works not like it is said in
Documentation/filesystems/proc.txt.
So apps which try to be MM friendly can silently break due to
very-very lazy memory allocation in kernel. Not nice when malloc() says
"everything is fine!".
[ Just checked: with overcommit==-1, as soon app trying to touch
those magic 2.8GB of memory, it gets killed by oom_killer. This is
totally wrong... ]
Probably fix docs at least... :-(
Marcelo Tosatti wrote:
>
> Hi,
>
> Yet another thing showed up (possible data corruption on x86-64), so here
> goes -rc5.
>
>
> Summary of changes from v2.4.23-rc4 to v2.4.23-rc5
> ============================================
>
> Andi Kleen:
> o Fix 32bit truncate64 on x86-64
>
> Marcelo Tosatti:
> o Felix Radensky: Remove debugging printk from agpgart
> o Changed EXTRAVERSION to -rc5
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Tue, 25 Nov 2003 17:50:20 +0100, you wrote in linux.kernel:
> "overcommit_memory < 0" supposed to not allow apps to overallocate
> memory - but still it works not like it is said in
> Documentation/filesystems/proc.txt.
That file mentiones setting overcommit_memory to 0 to disable overcommit.
Have you tried that?
--
Ciao,
Pascal
On Tue, 25 Nov 2003 17:50:20 +0100, you wrote in linux.kernel:
> "overcommit_memory < 0" supposed to not allow apps to overallocate
> memory - but still it works not like it is said in
> Documentation/filesystems/proc.txt.
Actually, looking at vm_enough_memory in mm/mmap.c in 2.4, which seems to
be the only user of sysctl_overcommit_memory, it is just used directly in
an if clause:
if (sysctl_overcommit_memory)
return 1;
This means any value different from 0 will turn overcommit on, no matter
whether positive or negative value.
Documentation bug, I would say.
--
Ciao,
Pascal
On Tue, Nov 25, 2003 at 09:42:21AM -0200, Marcelo Tosatti wrote:
>
>
> Hi,
>
> Yet another thing showed up (possible data corruption on x86-64), so here
> goes -rc5.
Sorry for not reading the entire 100+ message thread, but maybe someone can
answer anyway.
Will 2.4.23 have the oom killer?
On Tue, 25 Nov 2003, Mike Fedyk wrote:
> On Tue, Nov 25, 2003 at 09:42:21AM -0200, Marcelo Tosatti wrote:
> >
> >
> > Hi,
> >
> > Yet another thing showed up (possible data corruption on x86-64), so here
> > goes -rc5.
>
> Sorry for not reading the entire 100+ message thread, but maybe someone can
> answer anyway.
>
> Will 2.4.23 have the oom killer?
No. Andrea removed the oom killer because it had problems (deadlocks, it
can "guess" wrong in some cases).
It seems that in most cases killing the allocator (what 2.4.23 does)
works fine.
Having it configurable might be desired.
On Tue, 25 Nov 2003, Mike Fedyk wrote:
>> Will 2.4.23 have the oom killer?
On Tue, Nov 25, 2003 at 06:06:31PM -0200, Marcelo Tosatti wrote:
> No. Andrea removed the oom killer because it had problems (deadlocks, it
> can "guess" wrong in some cases).
> It seems that in most cases killing the allocator (what 2.4.23 does)
> works fine.
> Having it configurable might be desired.
Some of the bad behavior was due to races that disturbed the heuristics.
2.6 got those fixed and it made a large difference wrt. correcting its
bad behaviors. It's not infallible, but relatively well-behaved. (Not
that I could be arsed to debate whether that makes it worth keeping.)
-- wli
Pascal Schmidt wrote:
> On Tue, 25 Nov 2003 17:50:20 +0100, you wrote in linux.kernel:
>
>> "overcommit_memory < 0" supposed to not allow apps to overallocate
>>memory - but still it works not like it is said in
>>Documentation/filesystems/proc.txt.
>
>
> That file mentiones setting overcommit_memory to 0 to disable overcommit.
> Have you tried that?
>
Yes. This is kernel default on all my systems.
--
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
-- _ _ _
Because the kernel depends on it existing. "init" |_|*|_|
literally _is_ special from a kernel standpoint, |_|_|*|
because its' the "reaper of zombies" (and, may I add, |*|*|*|
that would be a great name for a rock band).
-- Linus Torvalds