Commit Graph

6 Commits

Author SHA1 Message Date
Gleb Smirnoff
c8d2ffd6a7 Merge all MD sf_buf allocators into one MI, residing in kern/subr_sfbuf.c
The MD allocators were very common, however there were some minor
differencies. These differencies were all consolidated in the MI allocator,
under ifdefs. The defines from machine/vmparam.h turn on features required
for a particular machine. For details look in the comment in sys/sf_buf.h.

As result no MD code left in sys/*/*/vm_machdep.c. Some arches still have
machine/sf_buf.h, which is usually quite small.

Tested by:	glebius (i386), tuexen (arm32), kevlo (arm32)
Reviewed by:	kib
Sponsored by:	Netflix
Sponsored by:	Nginx, Inc.
2014-08-05 09:44:10 +00:00
Ian Lepore
007aeeced6 Remove the ARM_USE_SMALL_ALLOC option and code related to it.
This was an optimization used only by a few xscale platforms.  Part of
the optimization was to create a direct map for all physical pages, and
that resulted in making multiple mappings of pages in a way that bypassed
the logic in pmap.c to handle VIVT cache aliasing.  It also just generally
made the code more complex and hard to maintain for all SoCs.

Reviewed by:	cognet
2014-02-08 22:21:38 +00:00
Gleb Smirnoff
fee4c621fc Fix of r255318: move sf_buf_alloc()/sf_buf_free() out of #ifdef
ARM_USE_SMALL_ALLOC.
2013-09-07 07:56:55 +00:00
Gleb Smirnoff
2ee9b44cae Fix build with gcc. Move sf_buf_alloc()/sf_buf_free() declarations
to MD headers.
2013-09-06 17:44:13 +00:00
Olivier Houchard
49953e11d7 Rewrite ARM_USE_SMALL_ALLOC so that instead of the current behavior, it maps
whole the physical memory, cached, using 1MB section mappings. This reduces
the address space available for user processes a bit, but given the amount of
memory a typical arm machine has, it is not (yet) a big issue.
It then provides a uma_small_alloc() that works as it does for architectures
which have a direct mapping.
2006-08-08 20:59:38 +00:00
Olivier Houchard
6fc729af63 Import FreeBSD/arm kernel bits.
It only supports sa1110 (on simics) right now, but xscale support should come
soon.
Some of the initial work has been provided by :
Stephane Potvin <sepotvin at videotron.ca>
Most of this comes from NetBSD.
2004-05-14 11:46:45 +00:00