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
53   * Untrusted allocations triggered from userspace should be a subject
67     example may be a hardware allocation that maps data directly into
79 :ref:`Documentation/core-api/gfp_mask-from-fs-io.rst <gfp_mask_from_fs_io>`.
82 used to ensure that the allocated memory is accessible by hardware
85 And even with hardware with restrictions it is preferable to use
89 ------------------------------
94   * ``GFP_KERNEL & ~__GFP_RECLAIM`` - optimistic allocation without _any_
100   * ``GFP_KERNEL & ~__GFP_DIRECT_RECLAIM`` (or ``GFP_NOWAIT``)- optimistic
107   * ``(GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM`` (aka ``GFP_ATOMIC``) -
109     some portion of memory reserves. Usually used from interrupt/bottom-half
112   * ``GFP_KERNEL`` - both background and direct reclaim are allowed and the
114     allocation requests are basically no-fail but there is no guarantee of
118   * ``GFP_KERNEL | __GFP_NORETRY`` - overrides the default allocator behavior
123   * ``GFP_KERNEL | __GFP_RETRY_MAYFAIL`` - overrides the default allocator
126     won't be triggered.
128   * ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior
143 limited. The actual limit depends on the hardware and the kernel
150 sizes, the alignment is guaranteed to be at least the largest power-of-two