Re: [m5-dev] big memory on a 32 bit machine
nathan binkert wrote: The reason I'd want to enumerate children is so I can find any memory objects below the CPU and determine what available ranges I can add into the map. If there ends up being in-memory-system address transformation in the future that could be more complicated, but for now just getting a list of accessible children would work. If, for some reason, somebody hooks up a sparse address space, it would be ideal to be able to find all the memory banks and put in a region for each of them. That would again be more complicated if there was some mechanism to get at memory that isn't a memory object child of that system, like for instance NUMA with nodes over an ethernet network, but it would be close enough for most cases I think. There is a call to get address ranges, and you should probably just have the CPU call that. It might not be perfect, so you might have to create a somewhat different one. If you need to create a different one, let me know first because I'd like to integrate the sendStatusChange stuff and the getAddressRange stuff. I'll look into this. For now though, I'd say that you should probably just have whatever SimObject that represents BIOS data just get a pointer to a list of memobjects. How would I get that list? Would I do that in C++ or in the python? Either is fine with me but I'm not clear on how that would work. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
For now though, I'd say that you should probably just have whatever SimObject that represents BIOS data just get a pointer to a list of memobjects. How would I get that list? Would I do that in C++ or in the python? Either is fine with me but I'm not clear on how that would work. Just add a python parameter to the bios object that is the PhysicalMemory object. Then your bios object can query it. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
I'm back in Ann Arbor waiting for my brother's surgery and I haven't had a chance to go back and get my desktop to work from, so I'm fiddling around with trying to get this to work. What I'm thinking to do is basically to just make the places I stick BIOS tables reserved and everything else up to the memory available available. That requires figuring out how much physical memory is in the system on the fly from the configuration script. Ideally it could also figure out sparsely populated address spaces. I know there's a way to look for the first -parent- that matches a particular type, but is there a way to enumerate all the children similarly? What are all the types of memory we support? I'm aware of a basic physical memory and a DRAM model. Maybe those should have an underlying base type to make it easier to find them all? Gabe Gabe Black wrote: I agree. This is something I plan to do once I get, for instance, a bash shell working just so I can have a mostly known working entity to start from and to cut down on where problems could be from. I'm going to have to spend some time in Edwardsburg (my parent's house) because of a family emergency so I brought my desktop back with me. I can work on that machine which won't have a problem with allocating 4 gigs until I make that configurable.. Gabe nathan binkert wrote: There's also a kernel command line option to override the bios notion of how much ram there is. Did you try that? No matter what you do, you must come up with a way to make the amount of memory configurable. On Sat, Apr 26, 2008 at 10:00 PM, Gabe Black [EMAIL PROTECTED] wrote: Well, it's not really just a value, it's a table of regions that are reserved or not. I'm not sure exactly how the regions are identified and I'd probably have to do a bunch of digging to figure out how to generate one. I think I'll just wait until I get back up to UM and use my desktop and avoid the whole problem. Gabe Ali Saidi wrote: We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
I'm not clear on exactly what you're doing here. Why is the area reserved? Are you talking about physical memory on the host? Why do you need to enumerate children? Details... Nate On Sat, May 3, 2008 at 8:27 AM, Gabe Black [EMAIL PROTECTED] wrote: I'm back in Ann Arbor waiting for my brother's surgery and I haven't had a chance to go back and get my desktop to work from, so I'm fiddling around with trying to get this to work. What I'm thinking to do is basically to just make the places I stick BIOS tables reserved and everything else up to the memory available available. That requires figuring out how much physical memory is in the system on the fly from the configuration script. Ideally it could also figure out sparsely populated address spaces. I know there's a way to look for the first -parent- that matches a particular type, but is there a way to enumerate all the children similarly? What are all the types of memory we support? I'm aware of a basic physical memory and a DRAM model. Maybe those should have an underlying base type to make it easier to find them all? Gabe Gabe Black wrote: I agree. This is something I plan to do once I get, for instance, a bash shell working just so I can have a mostly known working entity to start from and to cut down on where problems could be from. I'm going to have to spend some time in Edwardsburg (my parent's house) because of a family emergency so I brought my desktop back with me. I can work on that machine which won't have a problem with allocating 4 gigs until I make that configurable.. Gabe nathan binkert wrote: There's also a kernel command line option to override the bios notion of how much ram there is. Did you try that? No matter what you do, you must come up with a way to make the amount of memory configurable. On Sat, Apr 26, 2008 at 10:00 PM, Gabe Black [EMAIL PROTECTED] wrote: Well, it's not really just a value, it's a table of regions that are reserved or not. I'm not sure exactly how the regions are identified and I'd probably have to do a bunch of digging to figure out how to generate one. I think I'll just wait until I get back up to UM and use my desktop and avoid the whole problem. Gabe Ali Saidi wrote: We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org
Re: [m5-dev] big memory on a 32 bit machine
Basically, the e820 map is to tell the OS what areas of memory it can use and what areas hold the BIOS itself and the data tables it needs to operate. There are some areas in higher addresses which I'm not sure what they're for, but I suspect it's something to do with PCI devices or bridges or something. This is for physical memory in the host. Also, the map shows the OS what the highest physical address is it can expect to use. There are other BIOS mechanisms for determining that if you want to call into them, but they're OLD and have maximum return values like 16 MB. The reason I'd want to enumerate children is so I can find any memory objects below the CPU and determine what available ranges I can add into the map. If there ends up being in-memory-system address transformation in the future that could be more complicated, but for now just getting a list of accessible children would work. If, for some reason, somebody hooks up a sparse address space, it would be ideal to be able to find all the memory banks and put in a region for each of them. That would again be more complicated if there was some mechanism to get at memory that isn't a memory object child of that system, like for instance NUMA with nodes over an ethernet network, but it would be close enough for most cases I think. Gabe nathan binkert wrote: I'm not clear on exactly what you're doing here. Why is the area reserved? Are you talking about physical memory on the host? Why do you need to enumerate children? Details... Nate On Sat, May 3, 2008 at 8:27 AM, Gabe Black [EMAIL PROTECTED] wrote: I'm back in Ann Arbor waiting for my brother's surgery and I haven't had a chance to go back and get my desktop to work from, so I'm fiddling around with trying to get this to work. What I'm thinking to do is basically to just make the places I stick BIOS tables reserved and everything else up to the memory available available. That requires figuring out how much physical memory is in the system on the fly from the configuration script. Ideally it could also figure out sparsely populated address spaces. I know there's a way to look for the first -parent- that matches a particular type, but is there a way to enumerate all the children similarly? What are all the types of memory we support? I'm aware of a basic physical memory and a DRAM model. Maybe those should have an underlying base type to make it easier to find them all? Gabe Gabe Black wrote: I agree. This is something I plan to do once I get, for instance, a bash shell working just so I can have a mostly known working entity to start from and to cut down on where problems could be from. I'm going to have to spend some time in Edwardsburg (my parent's house) because of a family emergency so I brought my desktop back with me. I can work on that machine which won't have a problem with allocating 4 gigs until I make that configurable.. Gabe nathan binkert wrote: There's also a kernel command line option to override the bios notion of how much ram there is. Did you try that? No matter what you do, you must come up with a way to make the amount of memory configurable. On Sat, Apr 26, 2008 at 10:00 PM, Gabe Black [EMAIL PROTECTED] wrote: Well, it's not really just a value, it's a table of regions that are reserved or not. I'm not sure exactly how the regions are identified and I'd probably have to do a bunch of digging to figure out how to generate one. I think I'll just wait until I get back up to UM and use my desktop and avoid the whole problem. Gabe Ali Saidi wrote: We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember
Re: [m5-dev] big memory on a 32 bit machine
The reason I'd want to enumerate children is so I can find any memory objects below the CPU and determine what available ranges I can add into the map. If there ends up being in-memory-system address transformation in the future that could be more complicated, but for now just getting a list of accessible children would work. If, for some reason, somebody hooks up a sparse address space, it would be ideal to be able to find all the memory banks and put in a region for each of them. That would again be more complicated if there was some mechanism to get at memory that isn't a memory object child of that system, like for instance NUMA with nodes over an ethernet network, but it would be close enough for most cases I think. There is a call to get address ranges, and you should probably just have the CPU call that. It might not be perfect, so you might have to create a somewhat different one. If you need to create a different one, let me know first because I'd like to integrate the sendStatusChange stuff and the getAddressRange stuff. For now though, I'd say that you should probably just have whatever SimObject that represents BIOS data just get a pointer to a list of memobjects. Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
There's also a kernel command line option to override the bios notion of how much ram there is. Did you try that? No matter what you do, you must come up with a way to make the amount of memory configurable. On Sat, Apr 26, 2008 at 10:00 PM, Gabe Black [EMAIL PROTECTED] wrote: Well, it's not really just a value, it's a table of regions that are reserved or not. I'm not sure exactly how the regions are identified and I'd probably have to do a bunch of digging to figure out how to generate one. I think I'll just wait until I get back up to UM and use my desktop and avoid the whole problem. Gabe Ali Saidi wrote: We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
I agree. This is something I plan to do once I get, for instance, a bash shell working just so I can have a mostly known working entity to start from and to cut down on where problems could be from. I'm going to have to spend some time in Edwardsburg (my parent's house) because of a family emergency so I brought my desktop back with me. I can work on that machine which won't have a problem with allocating 4 gigs until I make that configurable.. Gabe nathan binkert wrote: There's also a kernel command line option to override the bios notion of how much ram there is. Did you try that? No matter what you do, you must come up with a way to make the amount of memory configurable. On Sat, Apr 26, 2008 at 10:00 PM, Gabe Black [EMAIL PROTECTED] wrote: Well, it's not really just a value, it's a table of regions that are reserved or not. I'm not sure exactly how the regions are identified and I'd probably have to do a bunch of digging to figure out how to generate one. I think I'll just wait until I get back up to UM and use my desktop and avoid the whole problem. Gabe Ali Saidi wrote: We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
Is it too difficult to track down which piece of BIOS info you copied contains the DRAM size, or copy the info from a machine with less RAM? In the long run we'll want to make it configurable, and clearly in the real world it's OK to have a PC with 4GB of RAM... On Sat, Apr 26, 2008 at 3:46 PM, Gabe Black [EMAIL PROTECTED] wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] big memory on a 32 bit machine
We talked about doing precisely that several years ago. You can also then compress the individual pages and also hash them so that you only need one copy of any page that's replicated. There is a probably a flyspray task to do just that, but no one got around to doing it. In the short term though I agree with Steve, just change the value in the BIOS. Ali On Apr 26, 2008, at 5:46 PM, Gabe Black wrote: To pass some time just now I went to try to figure out what seems like a fairly simple x86 bug on my laptop from my parent's house. It didn't work because my simulation wants to use 4 gigs of memory, and my laptop is 32 bit and can't fit that into m5's address space. The memory needs to be that large because of some information the BIOS provides which I copied from a different machine and which tells the kernel that's how much memory it should expect. Anyway, it seems like this, or something like it, would be an annoying limitation on the simulated system which depends on the guest. I read in a book I have about the linux virtual memory manager that there's some sort of mechanism for mmapping a part of a file at a time into a process, but unfortunately I don't remember the details. Something like that combined with some M5 level version of paging in and out of the file would get around that limitation. I imagine there being a different memory object (BigPhysical or something like that) to keep the complication out when it isn't needed. Anyway, what does everybody think? Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
