On Tue, 24 Feb 2026, Shakeel Butt wrote:
> On Tue, Feb 24, 2026 at 06:03:13AM -0800, Christoph Hellwig wrote:
> > On Tue, Feb 24, 2026 at 01:22:36PM +0100, Michal Hocko wrote:
> > > One thing that we could do to improve __GFP_RETRY_MAYFAIL resp.
> > > __GFP_NORETRY is to use NOWAIT allocation semantic for page table
> > > allocations as those could be achieved by scoped allocation context.
> > > This could cause pre-mature failure after the whole bunch of memory has
> > > already been allocated for the backing pages but considering that page
> > > table allocations should be more and more rare over system runtime it
> > > might be just a reasonable workaround. WDYT?
> >
> > Why bother? __GFP_RETRY_MAYFAIL has pretty lose semantics. Trying
> > too hard to allocate PTEs is not breaking the overall concept.
> >
>
> One thing __GFP_RETRY_MAYFAIL is very clear about is to not trigger the
> oom-killer which is not the case for GFP_KERNEL. There are users who
> explicitly
> use __GFP_RETRY_MAYFAIL to avoid oom-killer.
>
> Mikulas, is that the reason you are using __GFP_RETRY_MAYFAIL in your
> use-case?
The VDO is deduplication storage driver - it needs to allocate large
amounts of memory - for each disk block, it needs to store hash of the
data in memory to be able to detect blocks with duplicate data.
If the VDO driver attempts to allocate more memory than what is available,
we want the allocation to fail; we don't want to kill user processes.
Mikulas
