Apparently we're not the only ones thinking about the definitions of "free" memory.
This is from an Open Solaris mailing list and may help to clear up confusion (or further muddy the waters ) surrounding this issue. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Neale Ferguson Sent: Thursday, November 16, 2006 10:43 AM To: opensolaris-code@opensolaris.org Subject: [osol-code] Re: freemem 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 struct memlist *phys_avail; // list of memory available for use struct memlist *virt_avail; // list of virtual memory available for use There is also what appears to be an anchor: static struct memlist *memlist; 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); 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"? Neale This message posted from opensolaris.org _______________________________________________ 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
