Contributed by phessler on from the do-you-want-more-VM-sure-we-all-do dept.
Module name: src
Changes by: henning@cvs.openbsd.org 2005/02/19 10:58:03
Modified files:
sys/uvm : uvm_map.h
Log message:
double default MAX_KMAPENT to 2000, theo ok
everybody please update your trees and test this, we need to find out
wether there is bad side-effects from the doubling. If this does not get
enough testing by our user community we will play safe and revert this for
the 3.7 release, so please test.
it needs testing on all architectures, and especially on machines that
-now sometimes crash with the panic("uvm_mapent_alloc: out of static map entries, "
-that have little RAM
There will be snapshots up with this change soon - this is of course
the preferred way of testing.
Applying the diff manually is useless, especially it is absolutely
useless to test a 3.6-stable or something like that with this diff
applied, there were more changes in that area. Don't even bother, ok?
this is very important, so test test test!
To reiterate what Henning said, either run -current, or the new snapshots. Anything else won't help.
(Comments are closed)
By Anthony (68.145.111.152) on
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By Anthony (68.145.111.152) on
There's a ton of different things that cause problems if there aren't enough of them. I have to increase kern.maxfiles for example.
Comments
By jose (68.40.238.70) on http://monkey.org/~jose/
this change will delay that panic, it wont alleviate it. other people have been dealing with this for some time. check the netbsd archives for a further discussion, by the way, of the root cause and fixes.
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By Anthony (68.145.111.152) on
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By Brad (204.101.180.70) brad at comstyle dot com on
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By roo (195.137.43.11) on
By Nonesuch (24.148.72.216) on
I have many systems with uptime in excess of six months, and a few which have been up for nearly a year (only going down for the upgrade to 3.5 and then for an unplanned UPS "event" in May).
I have one system with an uptime of 200 days which processes several gigabytes/day of log events, and has not shown any signs of this UVM problem.
What type of system activity triggers the undesirable behavior?
Comments
By Anonymous Coward (81.64.227.144) on
Yes would be great to know ! I've some spare machines following -current (so, with the patch applied) that I want to stress, if that could increase 3.7 quality.
Comments
By jose (68.40.238.70) --@---.-- on http://monkey.org/~jose/
Comments
By Daniel (66.63.12.120) daniel@presscom.net on
By Anonymous Coward (83.147.128.114) on squid
Amavisd-new, too.
By jose (68.40.238.70) on http://monkey.org/~jose/
Comments
By Anonymous Coward (69.197.92.181) on
Comments
By Anthony (68.145.111.152) on
By jose (68.40.238.70) on http://monkey.org/~jose/
this bug is aggrevated by shared memory usage, ie in database systems like postgres. the kmap list grows as the memory map fragments (ie small chunks allocated), and list entries are consumed. after a while ... blam, panic.
Comments
By henning (80.86.183.226) on
Comments
By Anonymous Coward (217.43.158.188) on
By jose (68.40.238.70) --@---.-- on http://monkey.org/~jose/
notice that unlike you i'm trying to help by sharing what information i do have.
By henning (80.86.183.226) on
first, there was a very important change in that UVM area after 3.6 release, so all older results don't count any more anyway.
And claiming that increasing MAX_KMAPENTs just moves the poiint of panic is plain bullshit.
of course, if you run something that makes the kernel (want to) consume 10k entries it will crash with 1k or 2k, yeah...
By Anonymous Coward (83.147.128.114) on
This bug is very serious.
Comments
By Brad (204.101.180.70) brad at comstyle dot com on
Comments
By jose (68.40.238.70) --@---.-- on http://monkey.org/~jose/
kernel_map very fragmented?
kernel map entry merging and PR 24039
link: http://mail-index.netbsd.org/tech-kern/2004/12/.
you'll see a few things in there that are directly related, help illuminate the information about this problem and steps that can be taken to resolve it. it's probably the best info i can point you at offhand.
By rene (138.217.52.28) on
lighten up dudes.
By Anonymous Coward (81.64.227.144) on
Comments
By Brian (205.161.1.46) on
By Anonymous Coward (217.120.147.78) on
Comments
By Martin (62.178.75.222) martin@ on
Comments
By Han (217.120.147.78) han@mijncomputer.nl on
By ferywu (202.149.79.18) ferywu@corebsd.or.id on
build kernel
build userland
the effect is so great, sys-cache hit ratio always high
and every process feel more faster and ligther
even i don't use any timer to measure it.
especially for machine with squid+clamav+spamassassin+amavisd-new+mysql