I have this information
clock_rate(Ghz): 2
mem_access_latency(cycles): 250
L1_size(Bytes): 4096
L1_line_size(Bytes): 16
set_associativity: 2
in this information,
what's the cache size and blcok size?
and is it same to line_size and block size?
I can understand why this confusion. Lot of resources use cache, line, block terminology. After going through most of them, this is true to my knowledge.
Cache size = Cache capacity. In given info, L1_size(Bytes): 4096 Bytes
Block size= Cache block size = cache line size = line size. In given info, 16 Bytes
Related
I'm sorry if I made an error in posting this. Please let me know if I need to change anything.
I've received my computer architecture homework back and I missed this question. My professor's explanation didn't make sense to me, and I disagree with what he told me, so I am here asking what you guys think.
Here is the question:
A computer uses 16-bit memory addresses. Main memory is 512KB, and the cache is 1KB with 32B per block. Given each of the following mapping functions, calculate the number of bits in each field of the memory address.
Here is how I worked through the direct mapping part of the problem:
Cache memory: 1KB (2^10), 16-bit memory addresses (1 word = 2B) -> 1024B/2B = 512 words, 16 words per block (32B) -> 512/16 = 32 cache memory blocks.
Main memory: 512 KB (2^19), 16-bit memory addresses (1 word = 2B) -> 524288B/2B = 256K words, 16 words per block (32B) -> 256K/16 = 16384 or 16K main memory blocks.
I understand the word tag as such: 32B per block allows for 16 16-bit memory addresses per block. This (I believe) supports that: 1 word = 16 bits = 2 B -> 32B/2B = 16 words in each block. This equates to 2^4 = 4 bits for determining which word in the block, leaving 12 bits for tag and block bits in the memory address.
Now, in order to map 16K main memory blocks directly into 32 cache memory blocks, there will have to be 512 main memory blocks mapped to each cache memory block. So 512/16K blocks per 1/32 blocks.
Here is where I am confused. Doesn't this require 9 tag bits, as 2^9 = 512 (main memory blocks possibly mapped into one cache memory block)?
For the block bits, which point to a particular block in the cache, this requires 5 bits. 2^5 = 32, blocks in cache memory.
This would require 18 bits in the memory address.
Here is my professor's answer for this question:
2^5 = 32 -> 5 Word bits
(1KB)/(32B) = 32 blocks -> 5 Block bits
16 – 5 – 5 = 6 Tag bits
I did not realize I could simply subtract the required block and word bits to get the tag bits. But it still doesn't make sense to me. 2^6 = 64 blocks per cache block. 64*32 gives 2048. I can't wrap my head around this. Can someone please help?
Okay, the terminology that i learnt is slightly different but the principal should be the same for this explanation.
So cache will have multiple sets (sort of like a cell). And each set will have 1 cache line (containing 1 block of data) or multiple cache lines (each contain 1 block of data) (direct mapping or n-associativity mapping).
In mapping the main memory blocks to the cache, the main memory address (16 bit) is divided into 3 fields: tag, index bits and offset bits. A memory cell is 1 byte and a block is made up of a few cells
Offset bits are used to access the individual bytes of a memory block. Think of it as the offset on top of the block base address to get the byte you want (i assume your memory should be byte-addressable rather than word-addressable as it doesn't make sense to access 2B word as this would be inflexible) And here your prof/textbook call it as word bit. Hence if a block has 32 Bytes, there would be log2(block size) = 5 bits needed to access the individuals cells in the mapped block.
Index bits (in direct mapped cache is called block bits too as the number of set is the same as the number of blocks in the cache) is used to identify which set/cache line/ cache block that the main memory block is mapped to the cache. There are 1KB/32B = 32 cache blocks in the cache. As direct mapping is used, each set contain only 1 cache block and therefore there will be 32 set in this cache. Thus to access the correct set in cache, 5 bits is needed and therefore index bits = 5 bits
Tag is a name to determine if the data block in cache is the correct one we are looking one from the main memory. As the address of main memory is 16 bit and we already know index and offset fields, it is easy to deduce that tag will need 16 - 5 - 5 6 bits. How we determine the tag is not really a concern as the block size and cache size (and hence no. of sets in cache is given here).
Given a Cache with the following characteristics:
Main Memory: 16 bit Address
Cache Size: 256 Bytes
Cache Block Size: 8 Bytes
Cache Tag Size: 11 bits
What is the associativity of this Cache? Is it n-way Associative? If so what is n? Can someone please explain this so I can understand it?
Have a look at this nice illustration.
Here is how it works: Your address size is 16 bits, so you have 16 bits for the tag plus the index plus the offset within a cache block. If we assume that we want to address single bytes in the cache (which is usually the case), we need 3 bits to address 1 byte within a block (since each cache block is 8 = 2^3 bytes). That leaves 16 - 3 - 11 = 2 bytes for the index. With two bytes, we can address 2^2 = 4 different sets. We have 256 / 8 = 32 blocks in the cache (size of the cache / size of one block). Those 32 blocks are split into 4 sets, so each set holds 8 cache blocks. Your cache is thus 8-way associative.
can someone explain to me how to solve this problem?
A main memory has 128Mbytes and the size of a page is 2Kbytes. Consider that the memory is byte addressable. A process P has 6 logical pages (first logical page has the address 0).
a. What is the number of frames in this system?
b. How many bits are allocated to the page address?
a. Amount of main memory is 128MB which is 128 * 1024KB = 131,072KB. Since each page is 2KB that means you have 131,072KB / 2KB/page = 65,536 pages (or frames)
b. Page address is 2KB which 2^11 bytes. Assuming a system where the pages are in bytes that would imply that the number of bits for the page address is 11.
Since physical memory = 128 MB ➔ # frames = 128 MB / 2 KB = 2^15 frames ➔ number of
bits for frame number = 15 bits
This is an example from the book Computer Organization and Architecture by Stallings
The cache can hold 64 Kbytes
Data are transfered between main memory and the cache in blocks of 4 bytes each. This means that the cache is organized as 16K = 2^14 lines of 4 bytes each *.
The main memory has 16M. That is 2^24 words. So 4M blocks of 4 bytes.
My confusion is in the second point. It is said that each block is of 4 bytes that is 4 words of 8 bits so one block is 32 bits = 2^5. Now I want to get the number of blocks in the cache. For that I divide the size of the cache with the size of one block, that is 2^16(64K)/2^5(4bytes) = 2^11 lines of 4 bytes each but the answer is 2^14. What am I doing wrong? Thanks!
Its 64K Bytes so it will be 2^16 Bytes.
You will have to make it to bits so it will be (2^16 * 2^3 bits) / 2^5 bits = 2^14
Any one know how many bytes occupy per file in namenode of Hdfs?
I want to estimate how many files can store in single namenode of 32G memory.
Each file or directory or block occupies about 150 bytes in the namenode memory. [1] So a cluster with a namenode with 32G RAM can support a maximum of (assuming namenode is the bottleneck) about 38 million files. (Each file will also take up a block, so each file takes 300 bytes in effect. I am also assuming 3x replication. So each file takes up 900 bytes)
In practice however, the number will be much lesser because all of the 32G will not be available to the namenode for keeping the mapping. You can increase it by allocating more heap space to the namenode in that machine.
Replication also effects this to a lesser degree. Each additional replica adds about 16 bytes to the memory requirement. [2]
[1] https://blog.cloudera.com/small-files-big-foils-addressing-the-associated-metadata-and-application-challenges/
[2] http://search-hadoop.com/c/HDFS:/src/main/java/org/apache/hadoop/hdfs/server/blockmanagement/BlockInfo.java%7C%7CBlockInfo
Cloudera recommends 1 GB of NameNode heap space per million blocks. 1 GB for every million files is less conservative but should work too.
Also you don't need to multiply by a replication factor, an accepted answer is wrong.
Using the default block size of 128 MB, a file of 192 MB is split into two block files, one 128 MB file and one 64 MB file. On the NameNode, namespace objects are measured by the number of files and blocks. The same 192 MB file is represented by three namespace objects (1 file inode + 2 blocks) and consumes approximately 450 bytes of memory.
One data file of 128 MB is represented by two namespace objects on the NameNode (1 file inode + 1 block) and consumes approximately 300 bytes of memory. By contrast, 128 files of 1 MB each are represented by 256 namespace objects (128 file inodes + 128 blocks) and consume approximately 38,400 bytes.
Replication affects disk space but not memory consumption. Replication changes the amount of storage required for each block but not the number of blocks. If one block file on a DataNode, represented by one block on the NameNode, is replicated three times, the number of block files is tripled but not the number of blocks that represent them.
Examples:
1 x 1024 MB file
1 file inode
8 blocks (1024 MB / 128 MB)
Total = 9 objects * 150 bytes = 1,350 bytes of heap memory
8 x 128 MB files
8 file inodes
8 blocks
Total = 16 objects * 150 bytes = 2,400 bytes of heap memory
1,024 x 1 MB files
1,024 file inodes
1,024 blocks
Total = 2,048 objects * 150 bytes = 307,200 bytes of heap memory
Even more examples article in the origin article from cloudera.
(Each file metadata = 150bytes) + (block metadata for the file=150bytes)=300bytes
so 1million files each with 1 block will consume=300*1000000=300000000bytes
=300MB for replication factor of 1. with replication factor of 3 it requires 900MB.
So as thumb rule for every 1GB you can store 1million files.