Home
last modified time | relevance | path

Searched +full:64 +full:mb (Results 1 – 25 of 1039) sorted by relevance

12345678910>>...42

/linux-6.8/Documentation/arch/x86/x86_64/
Dmm.rst13 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 …]
/linux-6.8/arch/x86/kernel/cpu/
Dcacheinfo.c53 #define MB(x) ((x) * 1024) macro
62 { 0x09, LVL_1_INST, 32 }, /* 4-way set assoc, 64 byte line size */
65 { 0x0d, LVL_1_DATA, 16 }, /* 4-way set assoc, 64 byte line size */
66 { 0x0e, LVL_1_DATA, 24 }, /* 6-way set assoc, 64 byte line size */
67 { 0x21, LVL_2, 256 }, /* 8-way set assoc, 64 byte line size */
68 { 0x22, LVL_3, 512 }, /* 4-way set assoc, sectored cache, 64 byte line size */
69 { 0x23, LVL_3, MB(1) }, /* 8-way set assoc, sectored cache, 64 byte line size */
70 { 0x25, LVL_3, MB(2) }, /* 8-way set assoc, sectored cache, 64 byte line size */
71 { 0x29, LVL_3, MB(4) }, /* 8-way set assoc, sectored cache, 64 byte line size */
72 { 0x2c, LVL_1_DATA, 32 }, /* 8-way set assoc, 64 byte line size */
[all …]
/linux-6.8/arch/parisc/include/asm/
Dassembly.h20 #define FRAME_SIZE 64
26 /* Frame alignment for 32- and 64-bit */
27 #define FRAME_ALIGN 64
62 #define LDREGM ldd,mb
81 /* the 64-bit pa gnu assembler unfortunately defaults to .level 1.1 or 2.0 so
139 depd,z \r, 63-(\sa), 64-(\sa), \t
149 extrd,u \r, 63-(\sa), 64-(\sa), \t
152 /* Extract unsigned for 32- and 64-bit
312 fldd,mb -8(\regs), %fr30
313 fldd,mb -8(\regs), %fr29
[all …]
/linux-6.8/Documentation/admin-guide/cgroup-v1/
Dhugetlb.rst34 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 …]
/linux-6.8/tools/testing/selftests/tc-testing/tc-tests/qdiscs/
Dfq_codel.json17 …]+ limit 10240p flows 1024 quantum.*target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64",
38 …9]+ limit 1000p flows 1024 quantum.*target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64",
59 …limit 10240p flows 1024 quantum.*target 5ms interval 100ms memory_limit 100000b ecn drop_batch 64",
80 …]+ limit 10240p flows 1024 quantum.*target 2ms interval 100ms memory_limit 32Mb ecn drop_batch 64",
101 …-9]+ limit 10240p flows 1024 quantum.*target 5ms interval 5ms memory_limit 32Mb ecn drop_batch 64",
122 …imit 10240p flows 1024 quantum 9000 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64",
143 …[0-9]+ limit 10240p flows 1024 quantum.*target 5ms interval 100ms memory_limit 32Mb drop_batch 64",
164 …ws 1024 quantum.*target 5ms ce_threshold 1.02s interval 100ms memory_limit 32Mb ecn drop_batch 64",
185 …+ limit 10240p flows 1024 quantum.*target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 100",
206 …9]+ limit 1000p flows 256 quantum.*target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 100",
[all …]
/linux-6.8/drivers/accel/habanalabs/include/gaudi2/
Dgaudi2.h16 #define CFG_BAR_SIZE 0x10000000ull /* 256MB */
21 #define CFG_SIZE 0x8000000ull /* 96MB CFG + 32MB DBG*/
22 #define CFG_REGION_SIZE 0xC000000ull /* 192MB */
24 #define STM_FLASH_BASE_ADDR 0x1000007FF4000000ull /* Not 256MB aligned */
25 #define STM_FLASH_ALIGNED_OFF 0x4000000ull /* 256 MB alignment */
26 #define STM_FLASH_SIZE 0x2000000ull /* 32MB */
29 #define SPI_FLASH_SIZE 0x1000000ull /* 16MB */
32 #define SCRATCHPAD_SRAM_SIZE 0x10000ull /* 64KB */
38 #define BAR0_RSRVD_SIZE 0x1000000ull /* 16MB */
41 #define SRAM_SIZE 0x3000000ull /* 48MB */
[all …]
/linux-6.8/Documentation/devicetree/bindings/pci/
Dfaraday,ftpci100.yaml22 "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 */
Dv3-v360epc-pci.txt10 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 */
/linux-6.8/Documentation/arch/arm/
Dixp4xx.rst69 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
/linux-6.8/Documentation/translations/zh_TW/arch/arm64/
Dbooting.txt73 設備樹數據塊（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 …]
/linux-6.8/Documentation/translations/zh_CN/arch/arm64/
Dbooting.txt69 设备树数据块（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 …]
/linux-6.8/tools/perf/pmu-events/arch/arm64/freescale/yitian710/sys/
Dmetrics.json4 "BriefDescription": "The ddr read bandwidth(MB/s).",
6 "MetricExpr": "hif_rd * 64 / 1e6 / duration_time",
7 "ScaleUnit": "1MB/s",
13 "BriefDescription": "The ddr write bandwidth(MB/s).",
15 "MetricExpr": "(hif_wr + hif_rmw) * 64 / 1e6 / duration_time",
16 "ScaleUnit": "1MB/s",
/linux-6.8/drivers/accel/habanalabs/include/gaudi/
Dgaudi.h15 #define SRAM_BAR_SIZE 0x4000000ull /* 64MB */
16 #define CFG_BAR_SIZE 0x8000000ull /* 128MB */
19 #define CFG_SIZE 0x4000000 /* 32MB CFG + 32MB DBG*/
22 #define SRAM_SIZE 0x1400000 /* 20MB */
27 #define PSOC_SCRATCHPAD_SIZE 0x10000 /* 64KB */
/linux-6.8/include/linux/bcma/
Dbcma_regs.h76 #define BCMA_SOC_PCI_MEM 0x08000000U /* Host Mode sb2pcitranslation0 (64 MB) */
77 #define BCMA_SOC_PCI_MEM_SZ (64 * 1024 * 1024)
78 #define BCMA_SOC_PCI_CFG 0x0c000000U /* Host Mode sb2pcitranslation1 (64 MB) */
80 #define BCMA_SOC_SDRAM_R2 0x80000000U /* Region 2 for sdram (512 MB) */
93 #define BCMA_SOC_PCI1_MEM 0x40000000U /* Host Mode sb2pcitranslation0 (64 MB) */
94 #define BCMA_SOC_PCI1_CFG 0x44000000U /* Host Mode sb2pcitranslation1 (64 MB) */
/linux-6.8/arch/x86/pci/
Dce4100.c44 #define MB (1024 * 1024) macro
104 DEFINE_REG(2, 0, 0x10, (16*MB), reg_init, reg_read, reg_write)
106 DEFINE_REG(2, 1, 0x10, (64*KB), reg_init, reg_read, reg_write)
107 DEFINE_REG(3, 0, 0x10, (64*KB), reg_init, reg_read, reg_write)
112 DEFINE_REG(6, 2, 0x10, (64*KB), reg_init, reg_read, reg_write)
113 DEFINE_REG(8, 0, 0x10, (1*MB), reg_init, reg_read, reg_write)
114 DEFINE_REG(8, 1, 0x10, (64*KB), reg_init, reg_read, reg_write)
115 DEFINE_REG(8, 2, 0x10, (64*KB), reg_init, reg_read, reg_write)
116 DEFINE_REG(9, 0, 0x10 , (1*MB), reg_init, reg_read, reg_write)
117 DEFINE_REG(9, 0, 0x14, (64*KB), reg_init, reg_read, reg_write)
[all …]
/linux-6.8/arch/powerpc/include/asm/book3s/64/
Dhash-4k.h5 #define H_PTE_INDEX_SIZE 9 // size: 8B << 9 = 4KB, maps: 2^9 x 4KB = 2MB
6 #define H_PMD_INDEX_SIZE 7 // size: 8B << 7 = 1KB, maps: 2^7 x 2MB = 256MB
7 #define H_PUD_INDEX_SIZE 9 // size: 8B << 9 = 4KB, maps: 2^9 x 256MB = 128GB
8 #define H_PGD_INDEX_SIZE 9 // size: 8B << 9 = 4KB, maps: 2^9 x 128GB = 64TB
11 * Each context is 512TB. But on 4k we restrict our max TASK size to 64TB
12 * Hence also limit max EA bits to 64TB.
18 * Our page table limit us to 64TB. For 64TB physical memory, we only need 64GB
93 * 4K PTE format is different from 64K PTE format. Saving the hash_slot is just
94 * a matter of returning the PTE bits that need to be modified. On 64K PTE,
/linux-6.8/arch/arm64/include/asm/
Datomic_lse.h36 #define ATOMIC_FETCH_OP(name, mb, op, asm_op, cl...) \ argument
44 " " #asm_op #mb " %w[i], %w[old], %[v]" \
106 #define ATOMIC_FETCH_OP_AND(name, mb, cl...) \ argument
143 #define ATOMIC64_FETCH_OP(name, mb, op, asm_op, cl...) \ argument
151 " " #asm_op #mb " %[i], %[old], %[v]" \
213 #define ATOMIC64_FETCH_OP_AND(name, mb, cl...) \ argument
248 #define __CMPXCHG_CASE(w, sfx, name, sz, mb, cl...) \ argument
256 " cas" #mb #sfx " %" #w "[old], %" #w "[new], %[v]\n" \
268 __CMPXCHG_CASE(x, , , 64, )
272 __CMPXCHG_CASE(x, , acq_, 64, a, "memory")
[all …]
Datomic_ll_sc.h42 #define ATOMIC_OP_RETURN(name, mb, acq, rel, cl, op, asm_op, constraint)\ argument
55 " " #mb \
63 #define ATOMIC_FETCH_OP(name, mb, acq, rel, cl, op, asm_op, constraint) \ argument
76 " " #mb \
138 #define ATOMIC64_OP_RETURN(name, mb, acq, rel, cl, op, asm_op, constraint)\ argument
151 " " #mb \
159 #define ATOMIC64_FETCH_OP(name, mb, acq, rel, cl, op, asm_op, constraint)\ argument
172 " " #mb \
239 #define __CMPXCHG_CASE(w, sfx, name, sz, mb, acq, rel, cl, constraint) \ argument
263 " " #mb "\n" \
[all …]
/linux-6.8/Documentation/arch/xtensa/
Dmmu.rst62 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 …]
/linux-6.8/Documentation/arch/arm64/
Dmemory.rst9 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
38 fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
39 fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
40 fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
41 fffffbffff800000 fffffbffffffffff 8MB [guard region]
46 AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support)::
55 fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
56 fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
[all …]
/linux-6.8/Documentation/mm/
Dvmemmap_dedup.rst19 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 …]
/linux-6.8/arch/sparc/include/asm/
Dtsb.h7 * pointers into this table for 8K and 64K page sizes, and also a
151 * bit 23, for 8MB per PMD) we must propagate bit 22 for a
152 * 4MB huge page. For huge PUDs (which fall on bit 33, for
153 * 8GB per PUD), we have to accommodate 256MB and 2GB huge
159 sllx VADDR, 64 - (PGDIR_SHIFT + PGDIR_BITS), REG2; \
160 srlx REG2, 64 - PAGE_SHIFT, REG2; \
164 sllx VADDR, 64 - (PUD_SHIFT + PUD_BITS), REG2; \
165 srlx REG2, 64 - PAGE_SHIFT, REG2; \
176 sllx VADDR, 64 - (PMD_SHIFT + PMD_BITS), REG2; \
177 srlx REG2, 64 - PAGE_SHIFT, REG2; \
[all …]
/linux-6.8/Documentation/arch/riscv/
Dvm-layout.rst21 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 ffffffc6fea00000 | -228 GB | ffffffc6feffffff | 6 MB | fixmap
51 ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
53 ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
78 …0000800000000000 | +128 TB | ffff7fffffffffff | ~16M TB | ... huge, almost 64 bits wide hole of…
86 ffff8d7ffea00000 | -114.5 TB | ffff8d7ffeffffff | 6 MB | fixmap
87 ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io
90 … ffffaf8000000000 | -80.5 TB | ffffef7fffffffff | 64 TB | direct mapping of all physical memory
[all …]
/linux-6.8/arch/arm64/boot/dts/broadcom/northstar2/
Dns2-xmc.dts90 reg = <0x00000000 0x00280000>; /* 2.5MB */
96 reg = <0x00280000 0x00040000>; /* 0.25MB */
102 reg = <0x002c0000 0x00040000>; /* 0.25MB */
108 reg = <0x00300000 0x03d00000>; /* 61MB */
114 reg = <0x04000000 0x06400000>; /* 100MB */
119 reg = <0x0a400000 0x35c00000>; /* 860MB */
169 reg = <0x001e0000 0x00010000>;/* 64KB */
174 reg = <0x001f0000 0x00010000>; /* 64KB */
179 reg = <0x00200000 0x00e00000>; /* 14MB */
184 reg = <0x01000000 0x01000000>; /* 16MB */
/linux-6.8/arch/alpha/include/asm/
Dcore_apecs.h33 We put window 1 at BUS 64Mb for 64Mb, mapping physical 0 to 64Mb-1,
35 Yes, this does map 0 to 64Mb-1 twice, but only window 1 will actually
38 Note that we actually fudge the window 1 maximum as 48Mb instead of 64Mb,
40 a data area that goes beyond the 64Mb first DMA window. Sigh...
55 any physical memory accesses below 64Mb; the rest will be handled by
59 there will be no overlap at the top end (64Mb). We *must* locate the

12345678910>>...42