For what it's worth, he's the lowdown on how freemem is calculated for Solaris.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gavin Maltby Sent: Wednesday, November 22, 2006 3:38 AM To: Neale Ferguson Cc: opensolaris-code@opensolaris.org Subject: Re: [osol-code] Re: freemem 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 opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
