Lines Matching +full:hardware +full:- +full:triggered

35 :ref:`Documentation/core-api/mm-api.rst <mm-api-gfp-flags>` provides
43     direct reclaim may be triggered under memory pressure; the calling
52   * Untrusted allocations triggered from userspace should be a subject
66     example may be a hardware allocation that maps data directly into
78 :ref:`Documentation/core-api/gfp_mask-from-fs-io.rst <gfp_mask_from_fs_io>`.
81 used to ensure that the allocated memory is accessible by hardware
84 And even with hardware with restrictions it is preferable to use
88 ------------------------------
93   * ``GFP_KERNEL & ~__GFP_RECLAIM`` - optimistic allocation without _any_
99   * ``GFP_KERNEL & ~__GFP_DIRECT_RECLAIM`` (or ``GFP_NOWAIT``)- optimistic
106   * ``(GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM`` (aka ``GFP_ATOMIC``) -
108     some portion of memory reserves. Usually used from interrupt/bottom-half
111   * ``GFP_KERNEL`` - both background and direct reclaim are allowed and the
113     allocation requests are basically no-fail but there is no guarantee of
117   * ``GFP_KERNEL | __GFP_NORETRY`` - overrides the default allocator behavior
122   * ``GFP_KERNEL | __GFP_RETRY_MAYFAIL`` - overrides the default allocator
125     won't be triggered.
127   * ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior
142 limited. The actual limit depends on the hardware and the kernel