| History log of /src/sys/arch/next68k/include/vmparam.h |
| Revision | | Date | Author | Comments |
| 1.31 |
| 08-Feb-2025 |
tsutsui | Bump DFLSSIZ from 512KB to 2MB on all hp300 pmap m68k ports.
Some modern applications could require 512KB buffer on stack and
no particular comment on port-m68k@:
https://mail-index.netbsd.org/port-m68k/2025/02/02/msg000893.html
|
| 1.30 |
| 04-Feb-2023 |
tsutsui | branches: 1.30.6;
Remove trailing spaces and TABs.
|
| 1.29 |
| 04-Feb-2023 |
tsutsui | Remove leftover "last kernel PT page" settings derived from hp300.
Whilehere, also remove VM definitions for obsolete COMPAT_HPUX stuff.
All hp300 machines has RAMs at a region from the highest address
i.e. 0xFFFFFFFF to smaller address (as HP claims "it's the MSB first"),
so kernels have to prepare PA==KVA mappings as the "last PT page" to
guarantee the running kernel works both before and after the MMU is
turned on. For such a special mapping, we have to set up necessary
segment table and page table during early startup, in pmap_bootstrap()
invoked from locore.s.
On the other hand, NeXT machines have RAMs at a region from 0x40000000
to below (i.e. to larger address) so we still need a PA==KVA mapping.
However currently NetBSD/next68k just uses the transparent translation
registers to achieve the PA==KVA mapping, so unlike hp300 we don't have
to prepare special segment table and page table for it.
Note many other m68k ports (like luna68k, news68k, x68k etc.) have
RAMs at a region from 0x00000000 so usually we can assume PA==KVA
and don't have to bother to prepare such speicial mappings.
No user visible changes (except now freed wasted pages for the tables).
Tested on my NeXTstation slab.
|
| 1.28 |
| 05-Dec-2021 |
msaitoh | branches: 1.28.4;
s/from from/from/ in comment.
|
| 1.27 |
| 01-Feb-2020 |
tsutsui | Add MAX/MIN PAGE_SIZE and PAGE_SHIFT definitions of m68k for jemalloc(3).
Background:
- All m68k ports have fixed PAGE_SIZE value in their kernels,
but each port uses different PAGE_SIZE value (4096 or 8192)
due to historical reasons.
- Currently module(7) binaries are built per each port so
all m68k kernel sources don't support run-time variable PAGE_SIZE.
- MI <uvm/uvm_param.h> assumes that the port supports a variable
PAGE_SIZE on module(7) builds if both MAX_PAGE_SIZE and MIN_PAGE_SIZE
are defined and they have different values.
- On the other hand, jemalloc(3) checks MAX_PAGE_SHIFT in
src/external/bsd/jemalloc/include/jemalloc/internal/jemalloc_internal_defs.h
for internal optimization.
- m68k ports share userland binaries (especially pkgsrc binaries)
among all ports, so we need to define MAX_PAGE_SHIFT as 13 to
support m68k ports where PAGE_SIZE==8192.
(though this would affect only if static binaries built on
4k page hosts are executed on 8k page hosts)
To solve these inconsistency on PAGE_SIZE definitions,
we should have an independent PAGE_SIZE related definitions
for userland, but it requires major reorganization.
For now (especially for netbsd-9) we define MAX/MIN PAGE_SIZE and
PAGE_SHIFT values in <m68k/vmparam.h> only in !defined(_KERNEL) case.
Discussed on source-changes-d@ and tech-kern@ with christos@ and thorpej@:
https://mail-index.netbsd.org/source-changes-d/2020/01/thread1.html#012035
https://mail-index.netbsd.org/tech-kern/2020/01/thread1.html#025954
Should be pulled up to netbsd-9.
|
| 1.26 |
| 28-Jun-2019 |
tsutsui | branches: 1.26.2; 1.26.4;
Fix lingering page size comments.
Pointed out by christos@ on port-m68k@:
http://mail-index.netbsd.org/port-m68k/2019/06/06/msg000726.html
XXX: we also need MAX_PAGE_SIZE in somewhere for newer jemalloc?
|
| 1.25 |
| 02-Feb-2017 |
rin | branches: 1.25.14;
PR port-mac68k/51923
Bump default MAXTSIZ to 32MB for m68k ports, which allos us to use GCC 5.4 on
GENERIC kernels.
Ok jklos
|
| 1.24 |
| 02-Feb-2017 |
rin | PR port-mac68k/51923
Remove unused SYSPTSIZE and USRPTSIZE from m68k ports.
Ok jklos
|
| 1.23 |
| 08-Feb-2011 |
rmind | branches: 1.23.14; 1.23.32; 1.23.36; 1.23.40;
Remove clause 3 (UCB advertising clause) from the University of Utah
copyright. Confirmed by Mike Hibler, mike at cs.utah.edu - thanks!
Also, merge UCB and Utah copyright texts back into one, as they
originally were.
Extra verification by snj@.
|
| 1.22 |
| 06-Nov-2010 |
uebayasi | branches: 1.22.2; 1.22.4;
Remove incomplete, never worked dynamic run-time memory registration
(uvm_page_physload(9)). This functionality will be re-added later.
|
| 1.21 |
| 08-Dec-2009 |
tsutsui | branches: 1.21.2; 1.21.4;
Use PGSHIFT from <machine/param.h> for PAGE_SHIFT.
We can assume PGSHIFT is always constant on current
m68k pmap_motorola implementation.
Also fix some leftover HP300 comments on some ports.
|
| 1.20 |
| 26-Aug-2009 |
thorpej | Minor tweak to the pv_table management in the Hibler-derived m68k pmaps:
The head of the list is now a pv_header, which contains the first pv_entry
as well as a 16-bit attributes field (replaces the pmap_attributes array
plus the pv_entry::pv_flags field) as a 16-bit count of caller-specified
cache-inhibited mappings.
Tested on hp300 (shared pmap_motorola.c), changes to atari and amiga copies
are purely mechanical.
|
| 1.19 |
| 06-Mar-2009 |
joerg | Remove SHMMAXPGS from all kernel configs. Dynamically compute the
initial limit as 1/4 of the physical memory. Ensure the limit is at
least 1024 pages, the old default on most platforms.
|
| 1.18 |
| 11-Dec-2005 |
christos | branches: 1.18.78; 1.18.86; 1.18.92;
merge ktrace-lwp.
|
| 1.17 |
| 01-Apr-2005 |
yamt | merge yamt-km branch.
- don't use managed mappings/backing objects for wired memory allocations.
save some resources like pv_entry. also fix (most of) PR/27030.
- simplify kernel memory management API.
- simplify pmap bootstrap of some ports.
- some related cleanups.
|
| 1.16 |
| 07-Aug-2003 |
agc | branches: 1.16.8; 1.16.10;
Move UCB-licensed code from 4-clause to 3-clause licence.
Patches provided by Joel Baker in PR 22364, verified by myself.
|
| 1.15 |
| 02-Apr-2003 |
thorpej | branches: 1.15.2;
Use PAGE_SIZE rather than NBPG.
|
| 1.14 |
| 10-Dec-2002 |
thorpej | Use __LDPGSZ (which must be == USRTEXT) as the text address for a.out
executables, and eliminate the USRTEXT constant, which was only used
by the a.out exec code.
|
| 1.13 |
| 15-Nov-2001 |
soren | MAXSLP is defined to be a machine-independent scheduling parameter,
so move it into sys/param.h.
|
| 1.12 |
| 01-May-2001 |
thorpej | branches: 1.12.2; 1.12.8;
Per discussion w/ chuck and chuck, restructure the md page stuff
to use a structure called "vm_page_md", and use __HAVE_VM_PAGE_MD
and __HAVE_PMAP_PHYSSEG.
|
| 1.11 |
| 29-Apr-2001 |
thorpej | Add a VM_MDPAGE_MEMBERS macro that defines pmap-specific data for
each vm_page structure. Add a VM_MDPAGE_INIT() macro to init this
data when pages are initialized by UVM. These macros are mandatory,
but ports may #define them to nothing if they are not needed/used.
This deprecates struct pmap_physseg. As a transitional measure,
allow a port to #define PMAP_PHYSSEG so that it can continue to
use it until its pmap is converted to use VM_MDPAGE_MEMBERS.
Use all this stuff to eliminate a lot of extra work in the Alpha
pmap module (it's smaller and faster now). Changes to other pmap
modules will follow.
|
| 1.10 |
| 01-Dec-2000 |
tsutsui | branches: 1.10.2;
Remove unused pcbb() macro.
|
| 1.9 |
| 14-Nov-2000 |
thorpej | We use 4K pages on the NeXT. Define PAGE_SIZE and friends to be
compile-time constants.
|
| 1.8 |
| 11-Feb-2000 |
thorpej | Update for the NKMEMPAGES changes.
|
| 1.7 |
| 26-Jan-2000 |
tsutsui | Remove obsoleted macros.
|
| 1.6 |
| 04-Dec-1999 |
ragge | CL* discarding.
|
| 1.5 |
| 26-Apr-1999 |
thorpej | branches: 1.5.2; 1.5.8;
Garbage-collect the VM_MBUF_SIZE constant. Instead, use the size
(nmbclusters * mclbytes), so that the right amount of KVA space is
allocated if those variables are patched.
|
| 1.4 |
| 16-Jan-1999 |
chuck | branches: 1.4.4;
MNN is no longer optional
|
| 1.3 |
| 14-Nov-1998 |
dbj | Finished changes to use UVM on next68k.
Turn on UVM by default in GENERIC kernel.
|
| 1.2 |
| 28-Aug-1998 |
dbj | Updated many of the pmap files to use current versions from the
mvme68k port. The next68k port now uses MACHINE_NEW_NONCONTIG.
|
| 1.1 |
| 09-Jun-1998 |
dbj | branches: 1.1.1;
Initial revision
|
| 1.1.1.1 |
| 09-Jun-1998 |
dbj | Initial import of NetBSD/next68k.
|
| 1.4.4.1 |
| 21-Jun-1999 |
thorpej | Sync w/ -current.
|
| 1.5.8.1 |
| 27-Dec-1999 |
wrstuden | Pull up to last week's -current.
|
| 1.5.2.3 |
| 08-Dec-2000 |
bouyer | Sync with HEAD.
|
| 1.5.2.2 |
| 22-Nov-2000 |
bouyer | Sync with HEAD.
|
| 1.5.2.1 |
| 20-Nov-2000 |
bouyer | Update thorpej_scsipi to -current as of a month ago
A i386 GENERIC kernel compiles without the siop, ahc and bha drivers
(will be updated later). i386 IDE/ATAPI and ncr work, as well as
sparc/esp_sbus. alpha should work as well (untested yet).
siop, ahc and bha will be updated once I've updated the branch to current
-current, as well as machine-dependant code.
|
| 1.10.2.1 |
| 21-Jun-2001 |
nathanw | Catch up to -current.
|
| 1.12.8.3 |
| 11-Dec-2002 |
thorpej | Sync with HEAD.
|
| 1.12.8.2 |
| 08-Jan-2002 |
nathanw | Catch up to -current.
|
| 1.12.8.1 |
| 01-May-2001 |
nathanw | file vmparam.h was added on branch nathanw_sa on 2002-01-08 00:26:58 +0000
|
| 1.12.2.1 |
| 10-Jan-2002 |
thorpej | Sync kqueue branch with -current.
|
| 1.15.2.4 |
| 01-Apr-2005 |
skrll | Sync with HEAD.
|
| 1.15.2.3 |
| 21-Sep-2004 |
skrll | Fix the sync with head I botched.
|
| 1.15.2.2 |
| 18-Sep-2004 |
skrll | Sync with HEAD.
|
| 1.15.2.1 |
| 03-Aug-2004 |
skrll | Sync with HEAD
|
| 1.16.10.1 |
| 23-Feb-2005 |
yamt | change kernel va layout, following mac68k.
|
| 1.16.8.1 |
| 29-Apr-2005 |
kent | sync with -current
|
| 1.18.92.1 |
| 13-May-2009 |
jym | Sync with HEAD.
Commit is split, to avoid a "too many arguments" protocol error.
|
| 1.18.86.1 |
| 28-Apr-2009 |
skrll | Sync with HEAD.
|
| 1.18.78.3 |
| 11-Mar-2010 |
yamt | sync with head
|
| 1.18.78.2 |
| 16-Sep-2009 |
yamt | sync with head
|
| 1.18.78.1 |
| 04-May-2009 |
yamt | sync with head.
|
| 1.21.4.1 |
| 05-Mar-2011 |
rmind | sync with head
|
| 1.21.2.1 |
| 26-Apr-2010 |
uebayasi | Remove the unfinished code to add a memory segment after uvm_page_init().
It doesn't even compile.
(In the future, we should allocate struct vm_page [] on the added memory
segment for NUMA's sake.)
|
| 1.22.4.1 |
| 17-Feb-2011 |
bouyer | Sync with HEAD
|
| 1.22.2.1 |
| 06-Jun-2011 |
jruoho | Sync with HEAD.
|
| 1.23.40.1 |
| 21-Apr-2017 |
bouyer | Sync with HEAD
|
| 1.23.36.1 |
| 20-Mar-2017 |
pgoyette | Sync with HEAD
|
| 1.23.32.1 |
| 05-Feb-2017 |
skrll | Sync with HEAD
|
| 1.23.14.1 |
| 03-Dec-2017 |
jdolecek | update from HEAD
|
| 1.25.14.1 |
| 13-Apr-2020 |
martin | Mostly merge changes from HEAD upto 20200411
|
| 1.26.4.1 |
| 29-Feb-2020 |
ad | Sync with head.
|
| 1.26.2.2 |
| 12-Feb-2023 |
martin | Pull up following revision(s) (requested by tsutsui in ticket #1590):
sys/arch/next68k/include/vmparam.h: revision 1.29
sys/arch/next68k/next68k/machdep.c: revision 1.118
sys/arch/next68k/include/param.h: revision 1.13
sys/arch/next68k/next68k/pmap_bootstrap.c: revision 1.45
sys/arch/next68k/next68k/locore.s: revision 1.70
sys/arch/next68k/next68k/locore.s: revision 1.71
Use explicit CPU strings and remove hp300 derived stuff.
Remove #ifdef'ed out hp300 specific stuff.
Remove leftover "last kernel PT page" settings derived from hp300.
Whilehere, also remove VM definitions for obsolete COMPAT_HPUX stuff.
All hp300 machines has RAMs at a region from the highest address
i.e. 0xFFFFFFFF to smaller address (as HP claims "it's the MSB first"),
so kernels have to prepare PA==KVA mappings as the "last PT page" to
guarantee the running kernel works both before and after the MMU is
turned on. For such a special mapping, we have to set up necessary
segment table and page table during early startup, in pmap_bootstrap()
invoked from locore.s.
On the other hand, NeXT machines have RAMs at a region from 0x40000000
to below (i.e. to larger address) so we still need a PA==KVA mapping.
However currently NetBSD/next68k just uses the transparent translation
registers to achieve the PA==KVA mapping, so unlike hp300 we don't have
to prepare special segment table and page table for it.
Note many other m68k ports (like luna68k, news68k, x68k etc.) have
RAMs at a region from 0x00000000 so usually we can assume PA==KVA
and don't have to bother to prepare such speicial mappings.
No user visible changes (except now freed wasted pages for the tables).
Tested on my NeXTstation slab.
|
| 1.26.2.1 |
| 10-Feb-2020 |
martin | Pull up following revision(s) (requested by tsutsui in ticket #682):
sys/arch/next68k/include/vmparam.h: revision 1.27
sys/arch/mac68k/include/vmparam.h: revision 1.46
sys/arch/sun3/include/vmparam.h: revision 1.38
sys/arch/m68k/include/vmparam.h: revision 1.1
sys/arch/hp300/include/vmparam.h: revision 1.41
sys/arch/m68k/include/Makefile: revision 1.32
sys/arch/amiga/include/vmparam.h: revision 1.48
distrib/sets/lists/comp/ad.m68k: revision 1.63
sys/arch/x68k/include/vmparam.h: revision 1.40
sys/arch/mvme68k/include/vmparam.h: revision 1.38
sys/arch/luna68k/include/vmparam.h: revision 1.23
sys/arch/news68k/include/vmparam.h: revision 1.23
sys/arch/atari/include/vmparam.h: revision 1.34
sys/arch/cesfic/include/vmparam.h: revision 1.19
Add MAX/MIN PAGE_SIZE and PAGE_SHIFT definitions of m68k for jemalloc(3).
Background:
- All m68k ports have fixed PAGE_SIZE value in their kernels,
but each port uses different PAGE_SIZE value (4096 or 8192)
due to historical reasons.
- Currently module(7) binaries are built per each port so
all m68k kernel sources don't support run-time variable PAGE_SIZE.
- MI <uvm/uvm_param.h> assumes that the port supports a variable
PAGE_SIZE on module(7) builds if both MAX_PAGE_SIZE and MIN_PAGE_SIZE
are defined and they have different values.
- On the other hand, jemalloc(3) checks MAX_PAGE_SHIFT in
src/external/bsd/jemalloc/include/jemalloc/internal/jemalloc_internal_defs.h
for internal optimization.
- m68k ports share userland binaries (especially pkgsrc binaries)
among all ports, so we need to define MAX_PAGE_SHIFT as 13 to
support m68k ports where PAGE_SIZE==8192.
(though this would affect only if static binaries built on
4k page hosts are executed on 8k page hosts)
To solve these inconsistency on PAGE_SIZE definitions,
we should have an independent PAGE_SIZE related definitions
for userland, but it requires major reorganization.
For now (especially for netbsd-9) we define MAX/MIN PAGE_SIZE and
PAGE_SHIFT values in <m68k/vmparam.h> only in !defined(_KERNEL) case.
Discussed on source-changes-d@ and tech-kern@ with christos@ and thorpej@:
https://mail-index.netbsd.org/source-changes-d/2020/01/thread1.html#012035
https://mail-index.netbsd.org/tech-kern/2020/01/thread1.html#025954
Should be pulled up to netbsd-9.
|
| 1.28.4.1 |
| 12-Feb-2023 |
martin | Pull up following revision(s) (requested by tsutsui in ticket #77):
sys/arch/next68k/include/vmparam.h: revision 1.29
sys/arch/next68k/next68k/machdep.c: revision 1.118
sys/arch/next68k/include/param.h: revision 1.13
sys/arch/next68k/next68k/pmap_bootstrap.c: revision 1.45
sys/arch/next68k/next68k/locore.s: revision 1.70
sys/arch/next68k/next68k/locore.s: revision 1.71
Use explicit CPU strings and remove hp300 derived stuff.
Remove #ifdef'ed out hp300 specific stuff.
Remove leftover "last kernel PT page" settings derived from hp300.
Whilehere, also remove VM definitions for obsolete COMPAT_HPUX stuff.
All hp300 machines has RAMs at a region from the highest address
i.e. 0xFFFFFFFF to smaller address (as HP claims "it's the MSB first"),
so kernels have to prepare PA==KVA mappings as the "last PT page" to
guarantee the running kernel works both before and after the MMU is
turned on. For such a special mapping, we have to set up necessary
segment table and page table during early startup, in pmap_bootstrap()
invoked from locore.s.
On the other hand, NeXT machines have RAMs at a region from 0x40000000
to below (i.e. to larger address) so we still need a PA==KVA mapping.
However currently NetBSD/next68k just uses the transparent translation
registers to achieve the PA==KVA mapping, so unlike hp300 we don't have
to prepare special segment table and page table for it.
Note many other m68k ports (like luna68k, news68k, x68k etc.) have
RAMs at a region from 0x00000000 so usually we can assume PA==KVA
and don't have to bother to prepare such speicial mappings.
No user visible changes (except now freed wasted pages for the tables).
Tested on my NeXTstation slab.
|
| 1.30.6.1 |
| 02-Aug-2025 |
perseant | Sync with HEAD
|
