Searched +full:d +full:- +full:cache +full:- +full:size (Results 1 – 25 of 61) sorted by relevance
123
| /Documentation/devicetree/bindings/riscv/ |
| D | cpus.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR MIT) 3 --- 5 $schema: http://devicetree.org/meta-schemas/core.yaml# 7 title: RISC-V bindings for 'cpus' DT nodes 10 - Paul Walmsley <paul.walmsley@sifive.com> 11 - Palmer Dabbelt <palmer@sifive.com> 14 This document uses some terminology common to the RISC-V community 18 mandated by the RISC-V ISA: a PC and some registers. This 28 - items: 29 - enum: [all …]
|
| /Documentation/admin-guide/ |
| D | bcache.rst | 2 A block layer cache (bcache) 6 nice if you could use them as cache... Hence bcache. 10 - http://bcache.evilpiepirate.org 11 - http://evilpiepirate.org/git/linux-bcache.git 12 - http://evilpiepirate.org/git/bcache-tools.git 14 It's designed around the performance characteristics of SSDs - it only allocates 16 extents (which can be anywhere from a single sector to the bucket size). It's 22 great lengths to protect your data - it reliably handles unclean shutdown. (It 26 Writeback caching can use most of the cache for buffering writes - writing 33 average is above the cutoff it will skip all IO from that task - instead of [all …]
|
| /Documentation/core-api/ |
| D | cachetlb.rst | 2 Cache and TLB Flushing Under Linux 7 This document describes the cache/tlb flushing interfaces called 17 thinking SMP cache/tlb flushing must be so inefficient, this is in 24 "TLB" is abstracted under Linux as something the cpu uses to cache 25 virtual-->physical address translations obtained from the software 27 possible for stale translations to exist in this "TLB" cache. 59 modifications for the address space 'vma->vm_mm' in the range 60 'start' to 'end-1' will be visible to the cpu. That is, after 62 virtual addresses in the range 'start' to 'end-1'. 77 Linux to keep track of mmap'd regions for a process, the [all …]
|
| /Documentation/trace/ |
| D | events-kmem.rst | 8 - Slab allocation of small objects of unknown type (kmalloc) 9 - Slab allocation of small objects of known type 10 - Page allocation 11 - Per-CPU Allocator Activity 12 - External Fragmentation 22 kmalloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d 25 Heavy activity for these events may indicate that a specific cache is 37 kmem_cache_alloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d 40 These events are similar in usage to the kmalloc-related events except that 41 it is likely easier to pin the event down to a specific cache. At the time [all …]
|
| D | ftrace.rst | 2 ftrace - Function Tracer 13 - Written for: 2.6.28-rc2 14 - Updated for: 3.10 15 - Updated for: 4.13 - Copyright 2017 VMware Inc. Steven Rostedt 16 - Converted to rst format - Changbin Du <changbin.du@intel.com> 19 ------------ 24 performance issues that take place outside of user-space. 41 ---------------------- 43 See :doc:`ftrace-design` for details for arch porters and such. 47 --------------- [all …]
|
| /Documentation/filesystems/ |
| D | coda.txt | 3 Coda -- this document describes the client kernel-Venus interface. 10 To run Coda you need to get a user level cache manager for the client, 29 level filesystem code needed for the operation of the Coda file sys- 152 A key component in the Coda Distributed File System is the cache 160 client cache and makes remote procedure calls to Coda file servers and 179 leads to an almost natural environment for implementing a kernel-level 199 …l_o_s_e_, _c_r_e_a_t_e_, _m_k_d_i_r_, _r_m_d_i_r_, _c_h_m_o_d in a Unix 209 pre-processing, the VFS starts invoking exported routines in the FS 221 offered by the cache manager Venus. When the replies from Venus have 243 requesting detailed information about the persistent cache managed by [all …]
|
| D | ceph.txt | 12 * N-way replication of data across storage nodes 28 re-replicated in a distributed fashion by the storage nodes themselves 33 in-memory cache above the file namespace that is extremely scalable, 35 and can tolerate arbitrary (well, non-Byzantine) node failures. The 40 loaded into its cache with a single I/O operation. The contents of 57 files and bytes. That is, a 'getfattr -d foo' on any directory in the 68 setfattr -n ceph.quota.max_bytes -v 100000000 /some/dir 69 getfattr -n ceph.quota.max_bytes /some/dir 81 # mount -t ceph monip[:port][,monip2[:port]...]:/[subdir] mnt 89 # mount -t ceph 1.2.3.4:/ /mnt/ceph [all …]
|
| D | ramfs-rootfs-initramfs.txt | 7 -------------- 10 mechanisms (the page cache and dentry cache) as a dynamically resizable 11 RAM-based filesystem. 19 memory. A similar mechanism (the dentry cache) greatly speeds up access to 23 dentries and page cache as usual, but there's nowhere to write them to. 29 you're mounting the disk cache as a filesystem. Because of this, ramfs is not 34 ------------------ 38 device was of fixed size, so the filesystem mounted on it was of fixed 39 size. Using a ram disk also required unnecessarily copying memory from the 40 fake block device into the page cache (and copying changes back out), as well [all …]
|
| D | affs.txt | 15 in file names are case-insensitive, as they ought to be. 20 DOS\4 The original filesystem with directory cache. The directory 21 cache speeds up directory accesses on floppies considerably, 25 DOS\5 The Fast File System with directory cache. Supported read only. 70 verbose The volume name, file system type and block size will 90 Amiga -> Linux: 94 - R maps to r for user, group and others. On directories, R implies x. 96 - If both W and D are allowed, w will be set. 98 - E maps to x. 100 - H and P are always retained and ignored under Linux. [all …]
|
| D | f2fs.txt | 2 WHAT IS Flash-Friendly File System (F2FS)? 5 NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have 11 F2FS is a file system exploiting NAND flash memory-based storage devices, which 12 is based on Log-structured File System (LFS). The design has been focused on 16 Since a NAND flash memory-based storage device shows different characteristic 18 F2FS and its tools support various parameters not only for configuring on-disk 23 >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git 26 >> linux-f2fs-devel@lists.sourceforge.net 32 Log-structured File System (LFS) 33 -------------------------------- [all …]
|
| /Documentation/filesystems/caching/ |
| D | cachefiles.txt | 2 CacheFiles: CACHE ON ALREADY MOUNTED FILESYSTEM 13 (*) Starting the cache. 17 (*) Cache culling. 19 (*) Cache structure. 34 CacheFiles is a caching backend that's meant to use as a cache a directory on 37 CacheFiles uses a userspace daemon to do some of the cache management - such as 41 The filesystem and data integrity of the cache are only as good as those of the 46 CacheFiles creates a misc character device - "/dev/cachefiles" - that is used 48 and while it is open, a cache is at least partially in existence. The daemon 49 opens this and sends commands down it to control the cache. [all …]
|
| D | fscache.txt | 9 This facility is a general purpose cache for network filesystems, though it 12 FS-Cache mediates between cache backends (such as CacheFS) and network 15 +---------+ 16 | | +--------------+ 17 | NFS |--+ | | 18 | | | +-->| CacheFS | 19 +---------+ | +----------+ | | /dev/hda5 | 20 | | | | +--------------+ 21 +---------+ +-->| | | 22 | | | |--+ [all …]
|
| /Documentation/vm/ |
| D | slub.rst | 20 slabs that have data in them. See "slabinfo -h" for more options when 24 gcc -o slabinfo tools/vm/slabinfo.c 32 ------------------------------------------- 37 slub_debug=<Debug-Options> 40 slub_debug=<Debug-Options>,<slab name1>,<slab name2>,... 52 A Toggle failslab filter mark for the cache 55 - Switch all debugging off (useful if the kernel is 62 Trying to find an issue in the dentry cache? Try:: 66 to only enable debugging on the dentry cache. You may use an asterisk at the 68 example, here's how you can poison the dentry cache as well as all kmalloc [all …]
|
| D | frontswap.rst | 9 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk. 11 (Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends" 13 all other supporting code -- the "backends" -- is implemented as drivers. 21 a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming 23 in-kernel compressed memory, aka "zcache", or future RAM-like devices); 24 this pseudo-RAM device is not directly accessible or addressable by the 25 kernel and is of unknown and possibly time-varying size. The driver 49 cache" by calling frontswap_writethrough(). In this mode, the reduction 50 in swap device writes is lost (and also a non-trivial performance advantage) 87 and size (such as with compression) or secretly moved (as might be [all …]
|
| /Documentation/ |
| D | memory-barriers.txt | 19 documentation at tools/memory-model/. Nevertheless, even this memory 37 Note also that it is possible that a barrier may be a no-op for an 48 - Device operations. 49 - Guarantees. 53 - Varieties of memory barrier. 54 - What may not be assumed about memory barriers? 55 - Data dependency barriers (historical). 56 - Control dependencies. 57 - SMP barrier pairing. 58 - Examples of memory barrier sequences. [all …]
|
| D | DMA-API.txt | 8 of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt. 11 Part II describes extensions for supporting non-consistent memory 13 non-consistent platforms (this is usually only legacy platforms) you 16 Part I - dma_API 17 ---------------- 19 To get the dma_API, you must #include <linux/dma-mapping.h>. This 27 Part Ia - Using large DMA-coherent buffers 28 ------------------------------------------ 33 dma_alloc_coherent(struct device *dev, size_t size, 42 This routine allocates a region of <size> bytes of consistent memory. [all …]
|
| /Documentation/driver-api/usb/ |
| D | dma.rst | 12 though they still must provide DMA-ready buffers (see 13 ``Documentation/DMA-API-HOWTO.txt``). That's how they've worked through 14 the 2.4 (and earlier) kernels, or they can now be DMA-aware. 16 DMA-aware usb drivers: 18 - New calls enable DMA-aware drivers, letting them allocate dma buffers and 19 manage dma mappings for existing dma-ready buffers (see below). 21 - URBs have an additional "transfer_dma" field, as well as a transfer_flags 25 - "usbcore" will map this DMA address, if a DMA-aware driver didn't do 29 - There's a new "generic DMA API", parts of which are usable by USB device 37 and effects like cache-trashing can impose subtle penalties. [all …]
|
| /Documentation/devicetree/ |
| D | booting-without-of.txt | 2 -------------------------------------------------- 7 Freescale Semiconductor, FSL SOC and 32-bit additions 14 I - Introduction 21 II - The DT block format 27 III - Required content of the device tree 36 d) the /memory node(s) 40 IV - "dtc", the device tree compiler 42 V - Recommendations for a bootloader 44 VI - System-on-a-chip devices and nodes 48 VII - Specifying interrupt information for devices [all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | persistent-data.rst | 8 The more-sophisticated device-mapper targets require complex metadata 12 - Mikulas Patocka's multisnap implementation 13 - Heinz Mauelshagen's thin provisioning target 14 - Another btree-based caching target posted to dm-devel 15 - Another multi-snapshot target based on a design of Daniel Phillips 18 we'd like to reduce the number. 20 The persistent-data library is an attempt to provide a re-usable 21 framework for people who want to store metadata in device-mapper 22 targets. It's currently used by the thin-provisioning target and an 29 under drivers/md/persistent-data. [all …]
|
| /Documentation/networking/ |
| D | pktgen.txt | 4 ------------------------------------ 6 Enable CONFIG_NET_PKTGEN to compile and build pktgen either in-kernel 29 overload type of benchmarking, as this could hurt the normal use-case. 32 # ethtool -G ethX tx 1024 36 than the CPU's L1/L2 cache, 2) because it allows more queueing in the 41 ring-buffers for various performance reasons, and packets stalling 46 and the cleanup interval is affected by the ethtool --coalesce setting 47 of parameter "rx-usecs". 50 # ethtool -C ethX rx-usecs 30 67 * add_device DEVICE@NAME -- adds a single device [all …]
|
| /Documentation/admin-guide/blockdev/ |
| D | ramdisk.rst | 9 3) Using "rdev -r" 14 ----------- 18 in order to access the root filesystem (see Documentation/admin-guide/initrd.rst). It can 23 RAM from the buffer cache. The driver marks the buffers it is using as dirty 41 --------------------------------- 46 Size of the ramdisk. 48 This parameter tells the RAM disk driver to set up RAM disks of N k size. The 62 3) Using "rdev -r" 63 ------------------ 65 The usage of the word (two bytes) that "rdev -r" sets in the kernel image is [all …]
|
| /Documentation/virt/kvm/ |
| D | mmu.txt | 10 - correctness: the guest should not be able to determine that it is running 13 a particular implementation such as tlb size) 14 - security: the guest must not be able to touch host memory not assigned 16 - performance: minimize the performance penalty imposed by the mmu 17 - scaling: need to scale to large memory and large vcpu guests 18 - hardware: support the full range of x86 virtualization hardware 19 - integration: Linux memory management code must be in control of guest memory 22 - dirty tracking: report writes to guest memory to enable live migration 23 and framebuffer-based displays 24 - footprint: keep the amount of pinned kernel memory low (most memory [all …]
|
| /Documentation/arm/ |
| D | tcm.rst | 2 ARM TCM (Tightly-Coupled Memory) handling in Linux 7 Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory). 8 This is usually just a few (4-64) KiB of RAM inside the ARM 12 Harvard-architecture, so there is an ITCM (instruction TCM) 15 The size of DTCM or ITCM is minimum 4KiB so the typical 19 location and size of TCM memories. arch/arm/include/asm/cputype.h 24 determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present 29 size of TCM memories at runtime. This is used to read out and modify 30 TCM location and size. Notice that this is not a MMU table: you 52 - FIQ and other interrupt handlers that need deterministic [all …]
|
| /Documentation/ide/ |
| D | ChangeLog.ide-cd.1994-2004 | 2 * 1.00 Oct 31, 1994 -- Initial version. 3 * 1.01 Nov 2, 1994 -- Fixed problem with starting request in 5 * 1.03 Nov 25, 1994 -- leaving unmask_intr[] as a user-setting (as for disks) 6 * (from mlord) -- minor changes to cdrom_setup() 7 * -- renamed ide_dev_s to ide_drive_t, enable irq on command 8 * 2.00 Nov 27, 1994 -- Generalize packet command interface; 10 * 2.01 Dec 3, 1994 -- Rework packet command interface to handle devices 12 * 2.02 Dec 11, 1994 -- Cache the TOC in the driver. 18 * 2.03 Jan 10, 1995 -- Rewrite block read routines to handle block sizes 21 * 2.04 Apr 21, 1995 -- Add work-around for Creative Labs CD220E drives. [all …]
|
| /Documentation/ia64/ |
| D | err_inject.rst | 50 #corrected, data cache, hier-2, physical addr(assigned by tool code). 55 #corrected, data cache, hier-2, physical addr(assigned by tool code). 60 #recoverable, DTR0, hier-2. 111 #define ERR_DATA_BUFFER_SIZE 3 // Three 8-byte. 114 #define PATH_FORMAT "/sys/devices/system/cpu/cpu%d/err_inject/" 128 sprintf(fn, "%d.log", cpu); 132 return -1; 152 u64 mode : 3, /* 0-2 */ 153 err_inj : 3, /* 3-5 */ 154 err_sev : 2, /* 6-7 */ [all …]
|
123