Searched +full:64 +full:mb (Results 1 – 25 of 79) sorted by relevance
1234
| /Documentation/arch/x86/x86_64/ |
| D | mm.rst | 13 from the top of the 64-bit address space. It's easier to understand the layout
17 64-bit address space (ffffffffffffffff).
20 from TB to GB and then MB/KB.
24 It also shows it nicely how incredibly large 64-bit address space is.
35 …0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of…
45 …ffff888000000000 | -119.5 TB | ffffc87fffffffff | 64 TB | direct mapping of all physical memory…
63 ffffffef00000000 | -68 GB | fffffffeffffffff | 64 GB | EFI region mapping space
65 …ffffffff80000000 | -2 GB | ffffffff9fffffff | 512 MB | kernel text mapping, mapped to physic…
66 ffffffff80000000 |-2048 MB | | |
67 ffffffffa0000000 |-1536 MB | fffffffffeffffff | 1520 MB | module mapping space
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | hugetlb.rst | 34 For a system supporting three hugepage sizes (64k, 32M and 1G), the control
46 hugetlb.64KB.limit_in_bytes
47 hugetlb.64KB.max_usage_in_bytes
48 hugetlb.64KB.numa_stat
49 hugetlb.64KB.usage_in_bytes
50 hugetlb.64KB.failcnt
51 hugetlb.64KB.rsvd.limit_in_bytes
52 hugetlb.64KB.rsvd.max_usage_in_bytes
53 hugetlb.64KB.rsvd.usage_in_bytes
54 hugetlb.64KB.rsvd.failcnt
[all …]
|
| /Documentation/devicetree/bindings/pci/ |
| D | faraday,ftpci100.yaml | 22 "dual" variant has 64MiB. Take this into account when describing the ranges.
84 be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB, 64MB,
85 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked as
144 /* 64MiB at 0x00000000-0x03ffffff */
146 /* 64MiB at 0x00000000-0x03ffffff */
|
| D | v3-v360epc-pci.txt | 10 first the base address of the V3 host bridge controller, 64KB
11 second the configuration area register space, 16MB
18 each be exactly 256MB (0x10000000) in size.
22 be aligned to a 1MB boundary, and may be 1MB, 2MB, 4MB, 8MB, 16MB, 32MB,
23 64MB, 128MB, 256MB, 512MB, 1GB or 2GB in size. The memory should be marked
50 0x20000000 0 0x20000000 /* 512 MB @ LB 20000000 1:1 */
|
| D | intel,ixp4xx-pci.yaml | 38 description: Typically one memory range of 64MB and one IO
39 space range of 64KB.
44 the RAM is at. It can map only 64MB so if the RAM is bigger
45 than 64MB the DMA access has to be restricted to these
|
| /Documentation/translations/zh_CN/arch/arm64/ |
| D | booting.txt | 69 设备树数据块（dtb）必须 8 字节对齐，且大小不能超过 2MB。由于设备树
70 数据块将在使能缓存的情况下以 2MB 粒度被映射，故其不能被置于必须以特定
74 text_offset 字节处算起第一个 512MB 内。
91 已解压的内核映像包含一个 64 字节的头，内容如下：
121 - flags 域 (v3.17 引入) 为 64 位小端模式，其编码如下：
127 3 - 64K
129 0 - 2MB 对齐基址应尽量靠近内存起始处，因为
131 1 - 2MB 对齐基址可以在物理内存的任意位置
138 内核映像必须被放置在任意一个可用系统内存 2MB 对齐基址的 text_offset
139 字节处，并从该处被调用。2MB 对齐基址和内核映像起始地址之间的区域对于
[all …]
|
| /Documentation/translations/zh_TW/arch/arm64/ |
| D | booting.txt | 73 設備樹數據塊（dtb）必須 8 字節對齊，且大小不能超過 2MB。由於設備樹
74 數據塊將在使能緩存的情況下以 2MB 粒度被映射，故其不能被置於必須以特定
78 text_offset 字節處算起第一個 512MB 內。
95 已解壓的內核映像包含一個 64 字節的頭，內容如下：
125 - flags 域 (v3.17 引入) 爲 64 位小端模式，其編碼如下：
131 3 - 64K
133 0 - 2MB 對齊基址應儘量靠近內存起始處，因爲
135 1 - 2MB 對齊基址可以在物理內存的任意位置
142 內核映像必須被放置在任意一個可用系統內存 2MB 對齊基址的 text_offset
143 字節處，並從該處被調用。2MB 對齊基址和內核映像起始地址之間的區域對於
[all …]
|
| /Documentation/arch/arm/ |
| D | ixp4xx.rst | 69 The IXP4xx family allows for up to 256MB of memory but the PCI interface
70 can only expose 64MB of that memory to the PCI bus. This means that if
71 you are running with > 64MB, all PCI buffers outside of the accessible
78 1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB).
82 limits the system to just 64MB of PCI memory. This can be
85 2) If > 64MB of memory space is required, the IXP4xx can be
87 for up to 128MB (0x48000000 to 0x4fffffff) of memory on the bus.
125 also known as the Richfield board. It contains 4 PCI slots, 16MB
148 contains a CPU and 16MB of flash on the board and needs to be
|
| /Documentation/arch/riscv/ |
| D | vm-layout.rst | 21 RISC-V Linux Kernel 64bit
24 The RISC-V privileged architecture document states that the 64bit addresses
42 …0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... huge, almost 64 bits wide hole of…
50 ffffffc4fea00000 | -236 GB | ffffffc4feffffff | 6 MB | fixmap
51 ffffffc4ff000000 | -236 GB | ffffffc4ffffffff | 16 MB | PCI io
53 ffffffc600000000 | -232 GB | ffffffd5ffffffff | 64 GB | vmalloc/ioremap space
79 …0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of…
87 ffff8d7ffea00000 | -114.5 TB | ffff8d7ffeffffff | 6 MB | fixmap
88 ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io
91 … ffffaf8000000000 | -80.5 TB | ffffef7fffffffff | 64 TB | direct mapping of all physical memory
[all …]
|
| /Documentation/arch/arm64/ |
| D | memory.rst | 9 tables with a 4KB page size and up to 3 levels with a 64KB page size.
14 64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
18 only available when running with a 64KB page size and expands the
36 fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
37 fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
38 fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
39 fffffbffff800000 fffffbffffffffff 8MB [guard region]
44 AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
53 fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
54 fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
[all …]
|
| D | booting.rst | 56 the 512 MB region starting at text_offset bytes below the kernel Image.
75 The decompressed kernel image contains a 64-byte header as follows::
106 - The flags field (introduced in v3.17) is a little-endian 64-bit field
116 * 3 - 64K
120 2MB aligned base should be as close as possible
124 2MB aligned base such that all image_size bytes
135 The Image must be placed text_offset bytes from a 2MB aligned base
137 between the 2 MB aligned base address and the start of the image has no
456 naturally-aligned 64-bit zero-initalised memory location.
465 value. The value will be written as a single 64-bit little-endian
|
| /Documentation/arch/xtensa/ |
| D | mmu.rst | 62 5. The parent-bus-address value is rounded down to the nearest 256MB boundary
64 6. The IO area covers the entire 256MB segment of parent-bus-address; the
83 | VMALLOC area | VMALLOC_START 0xc0000000 128MB - 64KB
96 | | (4MB * DCACHE_N_COLORS)
104 | Cached KSEG | XCHAL_KSEG_CACHED_VADDR 0xd0000000 128MB
106 | Uncached KSEG | XCHAL_KSEG_BYPASS_VADDR 0xd8000000 128MB
108 | Cached KIO | XCHAL_KIO_CACHED_VADDR 0xe0000000 256MB
110 | Uncached KIO | XCHAL_KIO_BYPASS_VADDR 0xf0000000 256MB
114 256MB cached + 256MB uncached layout::
126 | VMALLOC area | VMALLOC_START 0xa0000000 128MB - 64KB
[all …]
|
| /Documentation/mm/ |
| D | vmemmap_dedup.rst | 19 details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are
20 currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page
34 architectures. Because arm64 supports 4k, 16k, and 64k base pages and
41 | x86-64 | 4KB | 2MB | 1GB | | |
43 | | 4KB | 64KB | 2MB | 32MB | 1GB |
45 | arm64 | 16KB | 2MB | 32MB | 1GB | |
47 | | 64KB | 2MB | 512MB | 16GB | |
73 = 64 / 8
79 This optimization only supports 64-bit system, so the value of sizeof(pte_t)
81 is a power of two. In most cases, the size of ``struct page`` is 64 bytes (e.g.
[all …]
|
| /Documentation/devicetree/bindings/mtd/ |
| D | ti,am654-hbmc.yaml | 56 ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */
57 <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */
|
| D | diskonchip.txt | 5 The Sandisk (formerly M-Systems) docg3 is a nand device of 64M to 256MB.
|
| /Documentation/translations/zh_CN/arch/riscv/ |
| D | vm-layout.rst | 28 64位 RISC-V Linux 内核
31 RISC-V特权架构文档指出，64位地址 "必须使第63-48位值都等于第47位，否则将发生缺页异常。"：这将虚
55 ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap
56 ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
58 ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
91 ffff8d7ffee00000 | -114.5 TB | ffff8d7ffeffffff | 2 MB | fixmap
92 ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io
95 ffffaf8000000000 | -80.5 TB | ffffef7fffffffff | 64 TB | 直接映射所有物理内存
|
| /Documentation/arch/powerpc/ |
| D | pci_iov_resource_on_powernv.rst | 90 0x8000_0000..0xffff_ffff. (Note: The top 64KB are actually
98 the segment granularity is 2GB/256 = 8MB.
112 * Must be at least 256MB in size.
127 for large BARs in 64-bit space:
130 that has been assigned by FW for the PHB (about 64GB, ignore the space
139 - We do the PE# allocation *after* the 64-bit space has been assigned
141 update the M32 PE# for the devices that use both 32-bit and 64-bit
180 1MB VF BAR0, the address in that VF BAR sets the base of an 8MB region.
181 This region is divided into eight contiguous 1MB regions, each of which
183 describes an 8MB region, the alignment requirement is for a single VF,
[all …]
|
| /Documentation/arch/x86/ |
| D | mtrr.rst | 73 reg00: base=0x00000000 ( 0MB), size= 128MB: write-back, count=1
74 reg01: base=0x08000000 ( 128MB), size= 64MB: write-back, count=1
87 reg00: base=0x00000000 ( 0MB), size= 128MB: write-back, count=1
88 reg01: base=0x08000000 ( 128MB), size= 64MB: write-back, count=1
89 reg02: base=0xf8000000 (3968MB), size= 4MB: write-combining, count=1
124 reg00: base=0x00000000 ( 0MB), size= 64MB: write-back, count=1
125 reg01: base=0xfb000000 (4016MB), size= 16MB: write-combining, count=1
126 reg02: base=0xfb000000 (4016MB), size= 4kB: uncachable, count=1
|
| /Documentation/arch/mips/ |
| D | booting.rst | 20 512MB of the physical address space (0x00000000 - 0x1fffffff),
21 aligned on a 64 bit boundary.
28 currently any 64-bit BMIPS implementations.
|
| /Documentation/scsi/ |
| D | sym53c8xx_2.rst | 151 |810 | N | N | FAST10 | 10 MB/s | N | N |
153 |810A | N | N | FAST10 | 10 MB/s | Y | N |
155 |815 | Y | N | FAST10 | 10 MB/s | N | N |
157 |825 | Y | Y | FAST10 | 20 MB/s | N | N |
159 |825A | Y | Y | FAST10 | 20 MB/s | Y | N |
161 |860 | N | N | FAST20 | 20 MB/s | Y | N |
163 |875 | Y | Y | FAST20 | 40 MB/s | Y | N |
165 |875A | Y | Y | FAST20 | 40 MB/s | Y | Y |
167 |876 | Y | Y | FAST20 | 40 MB/s | Y | N |
169 |895 | Y | Y | FAST40 | 80 MB/s | Y | N |
[all …]
|
| D | aha152x.rst | 19 least on my ancient test box; a i486/33Mhz/20MB).
150 to 64, the number of sectors to 32 and by calculating the number of
151 cylinders by dividing the capacity reported by the disk by 64*32 (1 MB).
159 (about 8 MB), as soon it sees a disk greater than 1 GB. That results
169 - for disks<1GB: use default translation (C/32/64)
175 ie. either (C/32/64) or (C/63/255)). This can be extended translation
|
| /Documentation/fb/ |
| D | intel810.rst | 88 select amount of system RAM in MB to allocate for the video memory
90 Recommendation: 1 - 4 MB.
123 select at what offset in MB of the logical memory to allocate the
126 offset (16 MB for a 64 MB aperture, 8 MB for a 32 MB aperture) will
127 avoid XFree86's usage and allows up to 7 MB/15 MB of framebuffer
129 (0 for maximum usage, 31/63 MB for the least amount). Note, an
133 (default = 8 or 16 MB)
195 will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
|
| /Documentation/devicetree/bindings/bus/ |
| D | qcom,ebi2.yaml | 20 Apparently this bus is clocked at 64MHz. It has dedicated pins on the package
28 memory is referred to as "Chip Peripheral SS FPB0" and is 168MB big.
31 CS0 GPIO134 0x1a800000-0x1b000000 (8MB)
32 CS1 GPIO39 (A) / GPIO123 (B) 0x1b000000-0x1b800000 (8MB)
33 CS2 GPIO40 (A) / GPIO124 (B) 0x1b800000-0x1c000000 (8MB)
34 CS3 GPIO133 0x1d000000-0x25000000 (128 MB)
35 CS4 GPIO132 0x1c800000-0x1d000000 (8MB)
36 CS5 GPIO131 0x1c000000-0x1c800000 (8MB)
|
| /Documentation/arch/s390/ |
| D | monreader.rst | 29 that the monitor DCSS begins at 144 MB and ends at 152 MB). You can query the
44 This defines two blocks of storage, the first is 140MB in size an begins at
45 address 0MB, the second is 200MB in size and begins at address 200MB,
46 resulting in a total storage of 340MB. Note that the first block should
47 always start at 0 and be at least 64MB in size.
59 This defines 140MB storage size for your guest, the parameter "mem=160M" is
|
| /Documentation/arch/sparc/oradax/ |
| D | oracle-dax.rst | 221 major caveat is that Linux on Sparc presents 8Mb as one of the huge
222 page sizes. Sparc does not actually provide a 8Mb hardware page size,
223 and this size is synthesized by pasting together two 4Mb pages. The
225 half of this 8Mb page can actually be used for any given buffer in a
227 it cannot be a 4Mb chunk in the middle, since that crosses a
234 A CCB is an array of 8 64-bit words. Several of these words provide
290 64-byte aligned and its size must be a multiple of 64 bytes because
338 if (pwrite(fd, ccb, 64, 0) != 64) {
406 hv_rv = sun4v_ccb_submit((unsigned long)ccb, 64,
|
1234