Hi,
On 11/16/06 17:42, Neale Ferguson wrote:
Actually, this question is redundant and arises because of a lack of
understanding of the way memlists work. I wonder if someone could step me
through the way things work here...
I'm trying to get my mind around the use of memlists in the startup code. I've modeled the System z code from the sun4 base.
I have three memory lists
struct memlist *phys_install; // list of memory making up the physical storage
This is the actual installed memory, eg on a SF6800 with 3 system boards:
> *phys_install::walk memlist | ::memlist
ADDR BASE SIZE
000003000041a2e0 0 400000000
000003000041a300 2000000000 400000000
000003000041a320 4000000000 180000000
struct memlist *phys_avail; // list of memory available for use
And, as you say, this is a subset of the above after various chunks have been
taken out of circulation for permanent kernel assignments etc. From the
same system:
> *phys_avail::walk memlist | ::memlist
ADDR BASE SIZE
000003000041a5c0 0 600000
000003000041a5e0 96c000 16000
000003000041a680 32aa000 156000
000003000041a600 3ca6000 35a000
000003000041a620 38cd6000 3c6eaa000
000003000041a640 2000000000 400000000
000003000041a660 4000000000 180000000
struct memlist *virt_avail; // list of virtual memory available for use
This, I think, is the unmapped virtual space at the point that OBP hands over
to the kernel; I don't think this list is maintained after that point.
> *virt_avail::walk memlist | ::memlist
ADDR BASE SIZE
000003000041a340 0 1000000
000003000041a360 1400000 400000
000003000041a380 1c00000 400000
000003000041a3a0 4800000 6b800000
000003000041a3c0 7041a000 7fbe6000
000003000041a3e0 f0080000 380000
000003000041a400 f1430000 33d0000
000003000041a420 f5466000 339a000
000003000041a440 f8b26000 3da000
000003000041a460 f9110000 6ee0000
000003000041a480 100000000 2ff00002000
000003000041a4a0 30000038000 a000
000003000041a4c0 30000588000 72000
000003000041a4e0 300005fe000 36000
000003000041a500 3000063a000 4000
000003000041a520 30000742000 34000
000003000041a540 3000078c000 874000
000003000041a560 30001cd6000 3fffe32a000
000003000041a580 70031c00000 fffff8fbce400000
000003000041a5a0 fffffffc00014000 3fffdc000
There is also what appears to be an anchor:
static struct memlist *memlist;
That is private to startup.c and is used in building the initial
memlist structures. In startup_memlist we allocate (using
BOP_ALLOC) enough space for and array of several struct memlist,
and point memlist to the beginning of this.
Thereafter memlist is used as a form of scratch space for various
operations. For example we point virt_avail to memlist and
then copy the boot_virtavail list there, then loop over the
list and push it all into the vmem arenas with vmem_xalloc.
Then we point phys_avail at memlist and copy the boot_physavail
list over it (whacking the previous bits) and calll kphysm_init
to iterate over that list and build page structures etc from it;
phys_avail seems actually to get finally set in startup_fixup_physavail.
My code determines the real storage configuration: number and size of chunks (usually one but System z does support discontiguous real memory). From this I should create the phys_install memory list. System z has not bootops etc. which means no boot memlist structures that need copying like sparc.
To create the memory list I'm doing:
phys_install = ndata_alloc(&ndata, nMemChunk * sizeof(memlist), sizeof(long));
for (i_Chunk = 0; i_Chunk < nMemChunk; i_Chunk++)
memlist_add((uintptr_t) sysMemory[i_Chunk].start, sysMemory[i_Chunk].len,
&phys_install, &phys_install);
The memlist_add for sun4 wants a pointer to an array of available struct memlist
(we use the memlist array allocated above for this) and a memory list to which
to
add the segment. Unless you have modified that function I suspect it will be
upset
at being called with &phys_install as the last two args above.
Which, if my understanding is correct, will create a memory list that describes
the physical memory installed. However, I don't believe this is correct but I'm
not sure why.
After setting up all my kernel structures etc. I have real memory that's unallocated which I can then add to the phys_avail memlist. This, I believe, describes real memory that is usable by the system. This storage may be comprised of discontiguous areas in the system (gaps between various areas or the vast expanse of unused memory from the end of kernel used areas to the top of real memory). I then create the phys_avail memlist by calling memlist_add to add these discontiguous areas.
Now the code allocates a memspace area that appears to have enough room for
many memlist entries. The code then states:
memlist = (struct memlist *) memspace;
phys_avail = memlist;
and there can be a sequence of memlist_add's to add the discontiguous pages to the
memlist list. However, I'm not sure I'm initializing the list correctly as the 1st
memlist_add works but subsequent ones fail because it claims the list is
"munged" (from memlist_insert).
I'm not sure as to the purpose of the struct memlist variable called "memlist" and how it is used by the rest of the memory management system.
Is there a "OpenSolaris Memlist Guide for Dummies"?
Self-documenting source? Actually the startup code is probably about as far
removed from
that as you can get!
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
