Age | Commit message (Collapse) | Author |
|
ok kettenis@ cloder@ tom@ henning@
|
|
ok dim@
|
|
most agp_generic_bind_memory failures when memory is limited and very
fragmented.
In effect, this should fix a lot of X startup crashes after
activities that exercise memory a lot (e.g. make builds, building big
ports, etc).
ok mickey, miod
|
|
|
|
In this commit:
- gdt lock on amd64
- sysctl lock
- malloc sysctl lock
- disk sysctl lock
- swap syscall lock
miod@, pedro@ ok (and "looks good" others@)
|
|
|
|
for cpu_swapin() on hppa* which is kept).
|
|
should never be referenced outside the context of the process to which
this stack belongs unless we do the PHOLD/PRELE dance. Loads of code
doesn't follow the rules here. Instead of trying to track down all
offenders and fix this hairy situation, it makes much more sense
to not swap kernel stacks.
From art@, tested by many some time ago.
|
|
pass zero; this will be used shortly. From art@
|
|
Okay weingart@, "I'm game with putting my name on it" dlg@
|
|
no change for normal code
|
|
miod@ ok
|
|
us did not see it or get a chance to test it before it was commited. It
broke cvs, in the ami driver, making it not succeed at seeing it's devices.
|
|
proper; found by krause and mmap_fixed
|
|
this results in lesse kva waste due to static preallocation of those
for every phys page and also every swap page.
tested by beck krw miod
|
|
|
|
|
|
will prevent panics in, e.g., bus_dmamem_alloc().
ok jason@ art@
|
|
defined; from NetBSD. Currently only used on xscale arm to use the mini data
cache for u area mappings instead of the main data cache.
|
|
|
|
1. drain hooks and lists of allocators make the code complicated
2. the only hooks in the system are the mbuf reclaim routines
3. if reclaim is actually able to put a meaningful amount of memory back
in the system, i think something else is dicked up. ie, if reclaiming
your ip fragment buffers makes the difference thrashing swap and not,
your system is in a load of trouble.
4. it's a scary amount of code running with very weird spl requirements
and i'd say it's pretty much totally untested. raise your hand if your
router is running at the edge of swap.
5. the reclaim stuff goes back to when mbufs lived in a tiny vm_map and
you could run out of va. that's very unlikely (like impossible) now.
ok/tested pedro krw sturm
|
|
as paddr_t could be a long long (soon) always cast and print as llx.
|
|
as freepages being vconverted back to byte address make sure to
perform calculations in (upcoming) larger paddr_t to avoid losing
higher bits in calculation.
|
|
physmem); miod@ toby@ ok
|
|
call uvm_unmap_p instead of uvm_unmap so that it has the process information
and can adjust vm_dused. okay pedro@ tedu@
|
|
page, so the arithmetic was ok. Spotted by david@
|
|
uvm_vsunlock(). ok mickey@
|
|
|
|
kettenis@ tedu@ ok
|
|
pgfree check into pglist; no functional change for normal kernels; make histories uncommon
|
|
ok deraadt@
|
|
by lint.
"Probably a bogus cut'n paste." says moid.
ok miod@ pedro@
|
|
|
|
14060 skip MADV_SEQUENTIAL if refaulting
18037 missing pageactivate
tested for some time by jolan krw
|
|
miod@ mickey@
|
|
of panics and bugfixes. Access curproc directly, do not expect a process
pointer as an argument. Should fix many "process context required" bugs.
Incentive and okay millert@, okay marc@. Various testing, thanks.
|
|
|
|
the protection of the memory mapping we're doing I/O on, or if we want to
leave them as they are. This should only be necessary for breakpoint
insertion in code, so we'll only use it for ptrace requests.
Initially from art@ after discussion with kettenis@ millert@ and I,
tested by many.
|
|
done in uvm_swapin(). Looks like this was a mistake made while editing. No
response from art@. deraadt@, miod@, pedro@ ok
|
|
practise. Depending on the list implementation, this might or might
not work; so make it use a safe idiom. ok pedro@ millert@ deraadt@
|
|
|
|
|
|
a proper fix has been implemented in uvm_mapent_alloc().
ok pedro@
|
|
|
|
the uvm_km_page allocator and use it instead of calling panic()
- add a counter to uvmexp so we can keep track of how many map entries
we have in use
idea from tedu@, long ago, okay deraadt@
|
|
arches; except on sparc where the range is 4-8 for !sun4m and 4-64 for sun4m,
selected at runtime.
|
|
|
|
- Use it to skip device mappings while dumping core.
- Ignore EFAULT errors while dumping core since they can happen
even for valid mappings. Just skip that part of the core file and
let it get automagically zero-filled.
This fixes the broken X core dumps that people have been seeing and also
fixes some other potential problems that could prevent core dumps (mmaps
beyond EOF, etc.).
tedu@ ok
|
|
|
|
over past week. as a bonus, kills 5 XXXs.
|