M.I.T. DEPARTMENT OF EECS
| 6.033 - Computer System Engineering | Handout 19 - March 10, 2000 |
New questions:
Q. In regards to the miss rate table, the miss rates deal with the regular memory before you do anything with compressing to memory, right? Also, that table lists memory from 24MB to 120MB, but they're only allowed to use the 32MB in the system, correct?
A: The table says: "If you have X MBytes of RAM, the miss rate is as shown." This means that the miss rate table applies to the compressed store as well. Think of it this way: with compression, you can make it look like you have more RAM than you actually do.
Yes, you're limited to 32 MB; you're supposed to design a virtual memory system. You're not allowed to add more RAM.
A: No. There's a line under things that don't need to be addressed in the design: "Hardware issues related to the processor, caches, memory, etc."
A: Yes, if you'd like to adjust processor speeds, that's OK, but you have to understand and justify the need to do so. Assume that the processing for compression and decompression are pipelined well-enough so that there are no idle cycles.
A: On average, you gain a factor of 4 by compressing (e.g., 10 Mbytes of data can be stored compressed in 2.5 Mbytes of RAM.) Some pages may not compress at all and others may compress by a factor of ten. The average over large, typical blocks of data is about 4.
Q: When compressing, does the processor do all the work or is any portion of memory needed during the compression cycles? It takes 32,000 cycles to compress a memory page. Can I assume that the memory page is taken little by little from main memory, compressed little by little and stored in its compressed form little by little in the main memory? Just trying to make sense of it.
A: I don't think you need to make this assumption. You already know how many cycles it takes; assume that all the energy and time consumption is accounted for by this. As described in the specification, don't worry about the extra space for tables etc. used in the compression algorithm.
BTW, the convention we've followed in 6.033 is that 1 KByte = 1024 bytes.
Q: How much memory is our user using at any time? Is is sufficient to hard limit the user to 80 Mb of memory?
A: It's up to you; as long as your design saves a significant amount of energy, it's good.
A: Do you mean disk startup? Or machine startup? Ignore the latter. Depending on your design, the former may be important. If your design is such that you make the disk idle for stretches of time, then restarting is important to consider in the energy-efficiency evaluation.
Q: The seek, read and write actions, with their 2.3W loss, get to a location, read a whole 8 KBytes page of data, and write a whole 8 KBytes page of data during the 10ms? Or is this just an assumption I can make?
A: Yes, this is correct.
Q: What is the burst read rate of the hard drive (in bytes/second)? What is the burst write rate of the hard drive (in bytes/second)?
A: The 10ms time includes the seek and rotational latency as well as the time to read (or write) and 8 KByte block. (The write and read rates themselves are large compared to the other latencies.)
Q: Does the executable image of the software need to be written to swapspace or can it be recovered from the executable file (Unix and MacOS do this)? What fraction of the memory used is executable and what fraction is data?
A: Assume that it's written to separate swapspace. Both code and data.
Q: Assume that only one 1 in 100 instructions is a memory access, and the processor is running as slow as possibly, at 33 Mhz. That leads to 330,000 memory accesses per second. Our main memory plus compressed backing store gives us 80 Mb of effective memory, with a miss rate of greater than .01%. This means that more than 33 times per second we will miss both main and backing store, and have to hit disk. If we were to spin the disk up and back down for each of these 33 accesses (rather than letting it run full time) we would be expending 33 * .09J = 2.97 Joules per second to spin the disk up each time. It is more efficient to keep the disk spun up (which only costs about .95 watts per second).
A: Right.
However, I'd argue about the 1 in 100 number for memory access; I think that with the I/D-caches in modern processors the numbers are a lot smaller than this. Also, miss rate numbers are very application dependent.
The miss rate number itself doesn't tell you anything about how frequently, in time, you need to go to memory.
You can make any reasonable assumption in your report to justify why it isn't (or is) advantageous to shut the disk off for portions of time.
Q: Is is possible to change the cache management algorithm, to agressively move pages from the backing store to the disk when the disk is spun up?
A: Yes, this is a possibility. Do you mean some kind of batching of all writes to disk? Yes, you can explore this.
A: Details are important, but remember the audience you're writing for are people who've taken 6.033. The description should be detailed enough that someone clued-in can go ahead and implement your ideas.
| Go to 6.033 Home Page | Questions or Comments: 6.033-tas@mit.edu
|