2011/4/19 Ariane van der Steldt <[email protected]>: > Your diff is reducable to: > static struct vm_map_entry kentries[REALLY_BIG_NUMBER]; > And then managing that memory using vmmap.
Yes, more or less... But your example eats VA memory and physical pages immediately and forever, while my diff tried to eat it on demand (it even may be constructed in a way to free physical pages when there will be many free kentries, in some cases of course)... > Your diff will generate problems with recursive locking: > 1) I need an entry for the kernel_map > lock: kernel_map. > 2) Therefor I need one from kentry_map, but I only have one left > lock: kentry_map. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ why? where you get it? > 3) I re-enter kentry_map to allocate a new entry > lock: kentry_map again! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that's must be first and right lock. it occures in uvm_map(kentry_map,...) when it called from uvm_km_kmemalloc(kentry_map,...). > potentially changed by step 3. Furthermore, simple_lock is a noop and > queued for destruction (use mutex instead). Yes. That's why I introduced mutex, as an example (but, my mistake, I missed it in uvm_mapent_free). > the malloc groups? Analyze the problem, why does it happen? Can you > narrow the behaviour down to a specific pattern? Once it freezes, break > into ddb and see what's running. What is the machine doing during the > freeze? Submit a bug report. :) Yes, yes... But usually it freezes to death, console not responding, so no ddb, no reports... > You are the only person I know of that has machines freezing because of > kentry pressure, assuming it is indeed related... Yes, again. I'm not 100% sure that it is because of kentries pressure, but it was a "signal". >> Of course. But it is completely predictable, not fatal (if we talk >> about kernel stability). > Predictable != non-fatal. So what? Predictable states are much easier to repeat, trace and debug than random states. > Running out of map entries is always fatal. We need to have them to be > able to create them. Oh... This is exactly what I try to avoid. If 1 kentry remain - allocate more. If can't - return it back, may be next try will success. >> And we are talking about kernel memory allocations, yes? It's all >> related to maps with VM_MAP_INTRSAFE flag. > For every magic value, users will prove its the wrong value. Are you about sysctl or VM_MAP_INTRSAFE flag? BTW, there are many sysctl values, in misc@ we can see that users play with them in a very strange ways. Making their system unusable. So what? Remove that? > I disagree with the idea itself. > The real problem is an architectural one. Ok, I got it. I hear same again and again, but did not hear that someone discussed the design new architecture, so the ideas gets accumulated in /dev/null. Looks like you mean to say to leave it, and try to be happy with amd64. Sad... -- antonvm
