2

Is the size of a memory page determined by the RAM itself, or by the OS? I.e., is the page size for a RAM the same for all OSes which use the RAM?

Is the size of a cluster of a file system determined by the file system itself, or by the OS which uses the file system? For example, is the cluster size of an ntfs partition the same when the partition is used under Linux and under Windows?

Thanks.

5

Memory page size
The constraints on the memory page size are primarily the MMU (Memory management Unit) hardware and performance criteria. Obviously the chosen page size has to be supported by the MMU (i.e. the page mapping hardware that provides virtual memory translations). Page size is chosen for the amount of code or data that should be swapped in or out when a page fault occurs (a small function is not in memory, so do we swap data out and read in just 1K of code or go for 8K of code?), and the cost of transferring that quantity of code/data (e.g. reading in two sectors is faster than reading 16 sectors).
Historically 4KiB has been a suitable balance for many systems. The actual size used is specified in the virtual memory code of the OS.

Cluster size
The cluster size is purely a filesystem unit, and the term "cluster" is primarily Microsoft terminology. The generic term is unit of allocation within a filesystem. The allocation unit is intrinsic to the specific installation of the filesystem (i.e. one NTFS partition can have a cluster size of 4 KiB and another NTFS partition on the same disk drive can have 64KiB clusters).

The filesystem allocation unit is primarily for bookkeeping of free (i.e. unallocated) versus in-use (i.e. allocated to files and directories) disk sectors (in the partition). Each file is composed of an ordered list of allocation units (i.e. clusters).

The allocation size is chosen/specified at the time of filesystem creation (i.e. formatting), and has to be based on some number of sectors (but preferably a power of 2), since the sector size is the fundamental unit of access and physical disk I/O. A small allocation size (such as just 1 sector) tends to have more negative (rather than positive, i.e. less wasted slack space) impact on filesystem (and disk) performance, such as a larger allocation table, more bookkeeping. A small allocation size also would constrain allocation addressing and total filesystem capacity. A large allocation size is beneficial when the filesystem has to span a large partition and/or the typical file size will be large (the large cluster size could reduce fragmentation) but at the expense of more wasted slack space.

Note that disk I/O does not have to be performed in units of the allocation size (e.g. if the file is less than a 512-byte sector long, the OS could chose to read only the first sector instead of the whole cluster). But any OS accessing a filesystem must adhere to its intrinsic allocation size (i.e. the allocation size cannot be changed).

Also see What are disk sectors for? and Downsides of a small allocation-unit size

| improve this answer | |
  • 1
    The OS typically reads quite a few pages at a time in order to take advantage of higher efficiencies in doing so. The choice of page size therefore doesn't have anything to do with IO performance, but rather the size of the page table. The smaller the page size, the more entries the page table needs to describe virtual memory, so you spend more memory on the page tables. Larger pages however, means you have less flexibility in dividing up that memory between different files or sections with different permissions. – psusi Jan 3 '15 at 2:09
  • 1
    Also modern cpus support large compound pages ( 4 MiB or 2 MiB ) that can be used to save page table entries for large extents of virtual memory with the same permissions and backing file. Linux has the ability to automatically use them where appropriate or programs can explicitly request them when allocating memory. Fewer page table entries also has a performance increase since they fit easier in the translation lookaside buffer so the cpu is less likely to need to waste time fetching them from ram. – psusi Jan 3 '15 at 2:13
  • @sawdust Thanks. (1) Wikipedia says "Page size is usually determined by processor architecture. " So is a memory's page size determined by the CPU? A memory may have different page sizes when it is used by different CPUs? (2) You said that MMU put constraints on page size, and if I am correct, MMU is part of a CPU, so is your reply consistent with Wikipedia? (3) Is the OS not involved in determining the page size? – Tim Jan 4 '15 at 20:08
  • (1) Only if the page size is fixed in HW. Otherwise the OS has control of the page size (within any constraints imposed by HW). Not sure what you mean by "a memory". Like a DIMM? In that case, yes. (2) Yes, the MMU is typically integrated with the CPU. (3) The OS is involved in determining the page size, as stated in the last line of my paragraph. – sawdust Jan 4 '15 at 23:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.