| /Documentation/filesystems/ |
| D | directory-locking.rst | 10 When taking the i_rwsem on multiple non-directory objects, we
11 always acquire the locks in order by increasing address. We'll call
22 * lock the directory we are accessing (shared)
26 * lock the directory we are accessing (exclusive)
73 in its own right; it may happen as part of lookup. We speak of the
74 operations on directory trees, but we obviously do not have the full
75 picture of those - especially for network filesystems. What we have
77 Trees grow as we do operations; memory pressure prunes them. Normally
78 that's not a problem, but there is a nasty twist - what should we do
83 possibility that directory we see in one place gets moved by the server
[all …]
|
| D | idmappings.rst | 23 on, we will always prefix ids with ``u`` or ``k`` to make it clear whether
24 we're talking about an id in the upper or lower idmapset.
42 that make it easier to understand how we can translate between idmappings. For
43 example, we know that the inverse idmapping is an order isomorphism as well::
49 Given that we are dealing with order isomorphisms plus the fact that we're
50 dealing with subsets we can embed idmappings into each other, i.e. we can
51 sensibly translate between different idmappings. For example, assume we've been
61 Because we're dealing with order isomorphic subsets it is meaningful to ask
64 mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using
69 If we were given the same task for the following three idmappings::
[all …]
|
| D | path-lookup.txt | 49 the path given by the name's starting point (which we know in advance -- eg.
55 A parent, of course, must be a directory, and we must have appropriate
79 In order to lookup a dcache (parent, name) tuple, we take a hash on the tuple
81 in that bucket is then walked, and we do a full comparison of each entry
148 However, when inserting object 2 onto a new list, we end up with this:
161 Because we didn't wait for a grace period, there may be a concurrent lookup
182 As explained above, we would like to do path walking without taking locks or
188 than reloading from the dentry later on (otherwise we'd have interesting things
192 no non-atomic stores to shared data), and to recheck the seqcount when we are
194 Avoiding destructive or changing operations means we can easily unwind from
[all …]
|
| /Documentation/filesystems/xfs/ |
| D | xfs-delayed-logging-design.rst | 15 We begin with an overview of transactions in XFS, followed by describing how
16 transaction reservations are structured and accounted, and then move into how we
18 reservations bounds. At this point we need to explain how relogging works. With
113 individual modification is atomic, the chain is *not atomic*. If we crash half
140 complete, we can explicitly tag a transaction as synchronous. This will trigger
145 throughput to the IO latency limitations of the underlying storage. Instead, we
161 available to write the modification into the journal before we start making
164 log in the worst case. This means that if we are modifying a btree in the
165 transaction, we have to reserve enough space to record a full leaf-to-root split
166 of the btree. As such, the reservations are quite complex because we have to
[all …]
|
| D | xfs-self-describing-metadata.rst | 32 However, if we scale the filesystem up to 1PB, we now have 10x as much metadata
44 magic number in the metadata block, we have no other way of identifying what it
45 is supposed to be. We can't even identify if it is the right place. Put simply,
57 Hence we need to record more information into the metadata to allow us to
59 of analysis. We can't protect against every possible type of error, but we can
66 hence parse and verify the metadata object. IF we can't independently identify
72 magic numbers. Hence we can change the on-disk format of all these objects to
76 self identifying and we can do much more expansive automated verification of the
80 integrity checking. We cannot trust the metadata if we cannot verify that it has
81 not been changed as a result of external influences. Hence we need some form of
[all …]
|
| /Documentation/driver-api/thermal/ |
| D | cpu-idle-cooling.rst | 25 because of the OPP density, we can only choose an OPP with a power
35 If we can remove the static and the dynamic leakage for a specific
38 injection period, we can mitigate the temperature by modulating the
47 At a specific OPP, we can assume that injecting idle cycle on all CPUs
49 idle state target residency, we lead to dropping the static and the
69 We use a fixed duration of idle injection that gives an acceptable
132 - It is less than or equal to the latency we tolerate when the
134 user experience, reactivity vs performance trade off we want. This
137 - It is greater than the idle state’s target residency we want to go
138 for thermal mitigation, otherwise we end up consuming more energy.
[all …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | sprd,pinctrl.txt | 12 to choose one function (like: UART0) for which system, since we
15 There are too much various configuration that we can not list all
16 of them, so we can not make every Spreadtrum-special configuration
18 global configuration in future. Then we add one "sprd,control" to
19 set these various global control configuration, and we need use
22 Moreover we recognise every fields comprising one bit or several
23 bits in one global control register as one pin, thus we should
32 Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
42 In some situation we need set the pin sleep mode and pin sleep related
45 sleep mode. For example, if we set the pin sleep mode as PUBCP_SLEEP
[all …]
|
| /Documentation/arch/x86/ |
| D | entry_64.rst | 58 so. If we mess that up even slightly, we crash.
60 So when we have a secondary entry, already in kernel mode, we *must
61 not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's
87 If we are at an interrupt or user-trap/gate-alike boundary then we can
89 whether SWAPGS was already done: if we see that we are a secondary
90 entry interrupting kernel mode execution, then we know that the GS
91 base has already been switched. If it says that we interrupted
92 user-space execution then we must do the SWAPGS.
94 But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context,
96 stack but before we executed SWAPGS, then the only safe way to check
[all …]
|
| /Documentation/dev-tools/kunit/ |
| D | run_wrapper.rst | 7 We can either run KUnit tests using kunit_tool or can run tests
10 As long as we can build the kernel, we can run KUnit.
21 We should see the following:
29 We may want to use the following options:
44 kunit_tool. This is useful if we have several different groups of
45 tests we want to run independently, or if we want to use pre-defined
64 If we want to run a specific set of tests (rather than those listed
65 in the KUnit ``defconfig``), we can provide Kconfig options in the
83 We can then add any other Kconfig options. For example:
90 set in the kernel ``.config`` before running the tests. It warns if we
[all …]
|
| /Documentation/arch/powerpc/ |
| D | pci_iov_resource_on_powernv.rst | 40 The following section provides a rough description of what we have on P8
52 For DMA, MSIs and inbound PCIe error messages, we have a table (in
55 We call this the RTT.
57 - For DMA we then provide an entire address space for each PE that can
63 - For MSIs, we have two windows in the address space (one at the top of
87 32-bit PCIe accesses. We configure that window at boot from FW and
91 reserved for MSIs but this is not a problem at this point; we just
93 ignores that however and will forward in that space if we try).
100 Now, this is the "main" window we use in Linux today (excluding
101 SR-IOV). We basically use the trick of forcing the bridge MMIO windows
[all …]
|
| D | kasan.txt | 39 checks can be delayed until after the MMU is set is up, and we can just not
44 linear mapping, using the same high-bits trick we use for the rest of the linear
47 - We'd like to place it near the start of physical memory. In theory we can do
48 this at run-time based on how much physical memory we have, but this requires
51 is hopefully something we can revisit once we get KASLR for Book3S.
53 - Alternatively, we can place the shadow at the _end_ of memory, but this
|
| /Documentation/gpu/amdgpu/display/ |
| D | dcn-overview.rst | 6 (DCN) works, we need to start with an overview of the hardware pipeline. Below
8 generic diagram, and we have variations per ASIC.
12 Based on this diagram, we can pass through each block and briefly describe
58 setup or ignored accordingly with userspace demands. For example, if we
77 From DCHUB to MPC, we have a representation called dc_plane; from MPC to OPTC,
78 we have dc_stream, and the output (DIO) is handled by dc_link. Keep in mind
100 a one-to-one mapping of the link encoder to PHY, but we can configure the DCN
123 depth format), bit-depth reduction/dithering would kick in. In OPP, we would
125 Eventually, we output data in integer format at DIO.
131 overloaded with multiple meanings, so it is important to define what we mean
[all …]
|
| D | index.rst | 22 DC case, we maintain a tree to centralize code from different parts. The shared
23 repository has integration tests with our Internal Linux CI farm, and we run a
28 When we upstream a new feature or some patches, we pack them in a patchset with
40 * Finally, developers wait a few days for community feedback before we merge
43 It is good to stress that the test phase is something that we take extremely
44 seriously, and we never merge anything that fails our validation. Follows an
62 In terms of test setup for CI and manual tests, we usually use:
65 #. In terms of userspace, we only use fully updated open-source components
67 #. Regarding IGT, we use the latest code from the upstream.
68 #. Most of the manual tests are conducted in the GNome but we also use KDE.
|
| D | mpo-overview.rst | 50 For this hardware example, we have 4 pipes (if you don't know what AMD pipe
59 hypothetical hardware that we are using as an example, we have an absolute
62 every DCN has different restrictions; here, we are just trying to provide the
86 Before we start to describe some restrictions around cursor and MPO, see the
120 .. note:: Keep in mind that we could extend this configuration to more planes,
121 but that is currently not supported by our driver yet (maybe if we have a
122 userspace request in the future, we can change that).
128 .. note:: We could extend this behavior to more planes, but that is currently
182 protect the plane that handles the video playback; notice that we don't have
190 Let's discuss some of the hardware limitations we have when dealing with
[all …]
|
| /Documentation/scheduler/ |
| D | schedutil.rst | 8 we know this is flawed, but it is the best workable approximation.
14 With PELT we track some metrics across the various scheduler entities, from
16 we use an Exponentially Weighted Moving Average (EWMA), each period (1024us)
35 Using this we track 2 key metrics: 'running' and 'runnable'. 'Running'
50 a big CPU, we allow architectures to scale the time delta with two ratios, one
53 For simple DVFS architectures (where software is in full control) we trivially
60 For more dynamic systems where the hardware is in control of DVFS we use
62 For Intel specifically, we use::
76 We pick 4C turbo over 1C turbo to make it slightly more sustainable.
84 of DVFS and CPU type. IOW. we can transfer and compare them between CPUs.
[all …]
|
| /Documentation/networking/ |
| D | fib_trie.rst | 37 verify that they actually do match the key we are searching for.
63 We have tried to keep the structure of the code as close to fib_hash as
72 fib_find_node(). Inserting a new node means we might have to run the
107 slower than the corresponding fib_hash function, as we have to walk the
123 The lookup is in its simplest form just like fib_find_node(). We descend the
124 trie, key segment by key segment, until we find a leaf. check_leaf() does
127 If we find a match, we are done.
129 If we don't find a match, we enter prefix matching mode. The prefix length,
131 and we backtrack upwards through the trie trying to find a longest matching
137 the child index until we find a match or the child index consists of nothing but
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | orphan.rst | 9 would leak. Similarly if we truncate or extend the file, we need not be able
10 to perform the operation in a single journalling transaction. In such case we
17 inode (we overload i_dtime inode field for this). However this filesystem
36 When a filesystem with orphan file feature is writeably mounted, we set
38 be valid orphan entries. In case we see this feature when mounting the
39 filesystem, we read the whole orphan file and process all orphan inodes found
40 there as usual. When cleanly unmounting the filesystem we remove the
|
| /Documentation/hid/ |
| D | hid-bpf.rst | 30 With HID-BPF, we can apply this filtering in the kernel directly so userspace
33 Of course, given that this dead zone is specific to an individual device, we
38 HID-BPF allows the userspace program to load the program itself, ensuring we
39 only load the custom API when we have a user.
48 We can reduce this burden by providing an eBPF program instead. Once such a
49 program has been verified by the user, we can embed the source code into the
62 Instead of using hidraw or creating new sysfs entries or ioctls, we can rely
82 screen we likely need to have a haptic click every 15 degrees. But when
89 What if we want to prevent other users to access a specific feature of a
92 With eBPF, we can intercept any HID command emitted to the device and
[all …]
|
| /Documentation/process/ |
| D | kernel-enforcement-statement.rst | 6 As developers of the Linux kernel, we have a keen interest in how our software
12 contributions made to our community, we share an interest in ensuring that
16 actions, we agree that it is in the best interests of our development
20 Notwithstanding the termination provisions of the GPL-2.0, we agree that
41 software. We want companies and individuals to use, modify and distribute
42 this software. We want to work with users in an open and transparent way to
44 enforcement that might limit adoption of our software. We view legal action
48 Finally, once a non-compliance issue is resolved, we hope the user will feel
49 welcome to join us in our efforts on this project. Working together, we will
52 Except where noted below, we speak only for ourselves, and not for any company
[all …]
|
| /Documentation/gpu/rfc/ |
| D | i915_small_bar.h | 6 * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS
61 * such systems we should never actually end up with a
62 * small BAR configuration, assuming we are able to load
98 * is immutable. Previously we would have two ioctls, one to create the object
101 * general we're phasing out the various SET/GET ioctls.
109 * Note that for some devices we have might have further minimum
136 * memory is directly visible/mappable through the CPU (which we also
139 * it's something we can expect to see in the wild. See
149 * that can *only* be placed in I915_MEMORY_CLASS_DEVICE, we therefore
162 * possible to end up with a small BAR configuration, assuming we can
[all …]
|
| /Documentation/sphinx/ |
| D | kernellog.py | 5 # as long as we support 1.4.
7 # We don't support 1.4 anymore, but we'll keep the wrappers around until
8 # we change all the code to not use them anymore :)
|
| /Documentation/filesystems/bcachefs/ |
| D | CodingStyle.rst | 34 we're not stuck debugging undefined behaviour should it turn out that you were
52 elide - if we were working in a language with embedded correctness proofs that
54 still be a few decades before it comes to systems programming languages. But we
64 introspection. We can't debug anything if we can't see what's going on.
66 Whenever we're debugging, and the solution isn't immediately obvious, if the
67 issue is that we don't know where the issue is because we can't see what's
70 We have the tools to make anything visible at runtime, efficiently - RCU and
83 labels, and good structure - we don't want files with a list of bare integers,
91 tool, but always look for more immediate ways to make things visible. When we
92 have to rely on tracing, we have to know which tracepoints we're looking for,
[all …]
|
| D | errorcodes.rst | 6 In bcachefs, as a hard rule we do not throw or directly use standard error
7 codes (-EINVAL, -EBUSY, etc.). Instead, we define private error codes as needed
19 At the module boundary, we use bch2_err_class() to convert to a standard error
24 be thrown in one place. That means that when we see it in a log message we can
|
| /Documentation/devicetree/bindings/i2c/ |
| D | i2c-arb-gpio-challenge.yaml | 30 others can see. These are all active low with pull-ups enabled. We'll
32 * OUR_CLAIM: output from us signaling to other hosts that we want the bus
39 Let's say we want to claim the bus. We:
43 3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we
61 The GPIO that we use to claim the bus.
78 We'll give up after this many microseconds.
83 We'll attempt another claim after this many microseconds.
|
| /Documentation/driver-api/firmware/ |
| D | lookup-order.rst | 9 * The ''Built-in firmware'' is checked first, if the firmware is present we
11 * The ''Firmware cache'' is looked at next. If the firmware is found we
13 * The ''Direct filesystem lookup'' is performed next, if found we
16 firmware_request_platform() is used, if found we return it immediately
|