summaryrefslogtreecommitdiffstats
path: root/sys/kern/kern_malloc.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Comment out recently added __attribute__((__format__(__kprintf__))) annotationsmiod2013-02-171-2/+2
| | | | | | in MI code; gcc 2.95 does not accept such annotation for function pointer declarations, only function prototypes. To be uncommented once gcc 2.95 bites the dust.
* Add explicit __attribute__ ((__format__(__kprintf__)))) to the functions andmiod2013-02-091-5/+6
| | | | | | function pointer arguments which are {used as,} wrappers around the kernel printf function. No functional change.
* Expand the panic to show the malloc type and size. Okay deraadt@.pirofti2012-03-301-2/+3
|
* New vmmap implementation.ariane2012-03-091-3/+8
| | | | | | | | | | | | no oks (it is really a pain to review properly) extensively tested, I'm confident it'll be stable 'now is the time' from several icb inhabitants Diff provides: - ability to specify different allocators for different regions/maps - a simpler implementation of the current allocator - currently in compatibility mode: it will generate similar addresses as the old allocator
* Improve kernel malloc type checking.jsing2011-09-221-2/+2
| | | | ok deraadt@
* Backout vmmap in order to repair virtual address selection algorithmsariane2011-06-061-8/+3
| | | | outside the tree.
* push kernel malloc(9) and kernel stacks into non-dma memory, since thatderaadt2011-06-061-2/+2
| | | | | | appears to be safe now. If not, we'll know soon where the bugs lie, so that we can fix them. This diff has been in snapshots for many months. ok oga miod
* Reimplement uvm/uvm_map.ariane2011-05-241-3/+8
| | | | | | | | | | | | | vmmap is designed to perform address space randomized allocations, without letting fragmentation of the address space go through the roof. Some highlights: - kernel address space randomization - proper implementation of guardpages - roughly 10% system time reduction during kernel build Tested by alot of people on tech@ and developers. Theo's machines are still happy.
* unify some pool and malloc flag values. the important bit is that all flagstedu2010-09-261-1/+3
| | | | | have real values, no 0 values anymore. ok deraadt kettenis krw matthew oga thib
* Add assertwaitok(9) to declare code paths that assume they can sleep.matthew2010-09-211-1/+4
| | | | | | | | | | Currently only checks that we're not in an interrupt context, but will soon check that we're not holding any mutexes either. Update malloc(9) and pool(9) to use assertwaitok(9) as appropriate. "i like it" art@, oga@, marco@; "i see no harm" deraadt@; too trivial for me to bother prying actual oks from people.
* We have this nice KMEMSTATS option to control when we use kmemstats,matthew2010-07-221-1/+3
| | | | | | so no point in reserving space for kmemstats unless it's enabled. ok thib@, deraadt@
* add an align argument to uvm_km_kmemalloc_pla.art2010-07-021-2/+2
| | | | | | | | | Use uvm_km_kmemalloc_pla with the dma constraint to allocate kernel stacks. Yes, that means DMA is possible to kernel stacks, but only until we've fixed all the scary drivers. deraadt@ ok
* constrain malloc to only grab pages from dma reachable memory.thib2010-07-011-4/+6
| | | | | | | Do this by calling uvm_km_kmemalloc_pla with the dma_constraint. ok art@ (ofcourse, he eats his cereal and okeys everything). OK beck@, deraadt@
* If option DIAGNOSTIC, do not bother doing sanity checks, including anmiod2009-08-251-16/+28
| | | | | | | | uvm_map_checkprot() call, if the memory we're about to return has just been allocated with uvm_km_kmemalloc() instead of coming from the freelist. No functional change but a very small speedup when the freelist for the given bucket is empty.
* The BUCKETINDX() giant macro is used to compute the base 2 logarithm of itsmiod2009-08-251-1/+33
| | | | | | | | | input, in order to pick the appropriate malloc() bucket. Replace it with an inline function in kern_malloc.c, which will either do a tightest-but-slower loop (if option SMALL_KERNEL), or a geometric search equivalent to what the macro does, but producing smaller code (especially on platforms which can not load large constants in one instruction).
* Don't enforce a minimum size for nkmempages by default; if the computedmiod2009-02-221-2/+2
| | | | | | | value (based on physmem) is below NKMEMPAGES_MIN, we are on a low memory machine and can not afford more anyway. ok deraadt@ tedu@
* Revert the change to use pools for <= PAGE_SIZE allocations. Itkettenis2008-10-181-124/+229
| | | | | | | | changes the pressure on the uvm system, uncovering several bugs. Some of those bugs result in provable deadlocks. We'll have to reconsider integrating this diff again after fixing those bugs. ok art@
* Since malloc_page_alloc() is a pool allocator it should check for PR_WAITOKkettenis2008-10-111-2/+3
| | | | | | | | instead of M_NOWAIT. Checking for M_NOWAIT made many malloc calls that used that flag actually wait. This probably explains many if the strange hangs people have seen recently. ok miod@
* In malloc_page_free(), restore the correct wire_count value.miod2008-10-051-2/+2
|
* Use pools to do allocations for all sizes <= PAGE_SIZE.art2008-09-291-229/+123
| | | | | | | | | | | This will allow us to escape the limitations of kmem_map. At this moment, the per-type limits are still enforced for all sizes, but we might loosen that limit in the future after some thinking. Original diff from Mickey in kernel/5761 , I massaged it a little to obey the per-type limits. miod@ ok
* Prevent possible free list corruption when malloc(9) sleeps.kettenis2008-02-211-3/+2
| | | | | | From NetBSD, kindly pointed out by YAMAMOTO Takashi. ok miod@
* replace ctob and btoc with ptoa and atop respectivelymartin2007-09-151-2/+2
| | | | help and ok miod@ thib@
* Add the long requested M_ZERO flag to malloc(9).art2007-09-071-4/+10
| | | | | | | | | | | But the reason for this isn't some kind of "we can make it use the pre-zeroed pages and zero the freelist in the idle loop and OMG I can has optimisatiuns" which would require tons of infrastructure and make everything slower. The reason is that it shrinks other code. And that's good. dlg@ ok, henning@ ok (before he read the diff)
* replace the machine dependant bytes-to-clicks macro by the MI ptoa()martin2007-09-011-3/+3
| | | | | | | | version for i386 more architectures and ctob() replacement is being worked on prodded by and ok miod
* Add a name argument to the RWLOCK_INITIALIZER macro.thib2007-05-291-2/+2
| | | | | | Pick reasonble names for the locks involved.. ok tedu@, art@
* Allow machine-dependant overrides for the ``deadbeef'' sentinel values,miod2007-04-121-1/+5
| | | | | | | | and make sure that nothing can ever be mapped at theses addresses. Only i386 overrides the default for now. From mickey@, ok art@ miod@
* Instead of managing pages for intrsafe maps in special objects (aka.art2007-04-111-4/+4
| | | | | | | | kmem_object) just so that we can remove them, just use pmap_extract to get the pages to free and simplify a lot of code to not deal with the list of intrsafe maps, intrsafe objects, etc. miod@ ok
* remove a few void * casts that are uselesstedu2007-03-251-4/+4
|
* Switch some lockmgr locks to rwlocks.art2007-01-121-4/+5
| | | | | | | | | | | 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@)
* Make malloc() print out a warning message when returning NULL due topedro2006-11-281-3/+14
| | | | M_CANFAIL, idea from miod@, okay deraadt@
* If M_CANFAIL is set and the malloc() size is to bigthib2006-11-221-3/+8
| | | | | | return NULL instead of panic()'ing. ok pedro@, deraadt@
* no malloc debug but configured kmemstats allow 'sh mal' to print smth useful; miod@ okmickey2006-09-301-1/+31
|
* ansi/deregister.jsg2005-11-281-25/+15
| | | | 'go for it' deraadt@
* Remove unnecessary lockmgr() archaism that was costing too much in termspedro2005-11-191-3/+3
| | | | | | 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.
* Change the NKMEMPAGES range to 4-64MB for 32bit arches, and 8-128MB for 64bitmiod2005-09-121-9/+22
| | | | | arches; except on sparc where the range is 4-8 for !sun4m and 4-64 for sun4m, selected at runtime.
* Import M_CANFAIL support from NetBSD, removes a nasty panic during low-mem scenarios, instead generating an ENOMEM backfeed, ok tedu@, prodded by manyniklas2004-12-301-5/+6
|
* bad stuff escaped by accidenttedu2004-05-231-2/+1
|
* according to fork1(9), retval is optional. make it so.tedu2004-05-231-1/+2
| | | | from form@pdp-11.org.ru via mpech. ok millert
* make check for too large allocations earlier, instead of fiddling with it.tedu2003-12-281-3/+3
| | | | | less error prone (no wraparound). no real functional change though. ok markus tdeval
* remove caddr_t casts. it's just silly to cast something when the functiontedu2003-07-211-4/+4
| | | | takes a void *. convert uiomove to take a void * as well. ok deraadt@
* addrmask canbe constmickey2003-06-261-2/+2
|
* Remove the advertising clause in the UCB license which Berkeleymillert2003-06-021-6/+2
| | | | rescinded 22 July 1999. Proofed by myself and Theo.
* uvm_km_suballoc passes the 'min' argument untouched to uvm_map. uvm_mapart2003-06-011-5/+8
| | | | | | | | uses it as a hint for where to steal space from the parent map. We've been passing random stack garbage as that hint for ages. It's a wonder it didn't break things until we started working on Hammer. noone objected for at least a week.
* string fixes; tedu okderaadt2003-05-031-8/+13
|
* woah. last commit contained way too much. revert, and apply only the change intended.tedu2003-04-101-23/+8
|
* off by one bounds check in diag code. ok art.tedu2003-04-101-9/+24
|
* splvm, not splimpart2002-06-111-3/+3
|
* malloc_roundup to calculate allocation size malloc will use; from netbsd;provos2002-02-121-1/+13
| | | | okay art@
* Don't include <sys/map.h> when you don't need what's in it.miod2002-01-161-2/+1
|
* UBC was a disaster. It worked very good when it worked, but on someart2001-12-191-3/+3
| | | | | | | | | machines or some configurations or in some phase of the moon (we actually don't know when or why) files disappeared. Since we've not been able to track down the problem in two weeks intense debugging and we need -current to be stable, back out everything to a state it had before UBC. We apologise for the inconvenience.