On Thu, Jun 25, 2026 at 11:19:19AM +0200, Michal Koutný wrote: > On Mon, Jun 22, 2026 at 12:26:54PM -0300, Thadeu Lima de Souza Cascardo > <[email protected]> wrote: > > As far as I understood the patchset, it doesn't fail the write if it fails > > to reclaim. It sets the new max, then, if the write is blocking, starts > > reclaim and eventually returns after multiple attempts. But it still > > returns success. > > > > So I believe this is behaving as you would expect. > > I was alarmed by the EBUSY mention similarly to Tejun but then I > couldn't find it in pre-patch (840ef6c78e6a2) nor in patched (v5) code. > Please make sure the EBUSY return behavior is not introduced > (essentially match memory.max behavior) and that the accompanying > message refers up to date code ;-) > > Michal
I think this is a reference to the fact that right now writing to dmem.max calls page_counter_set_max, which will return -EBUSY and fail to change the max value. It is just that we are not returning that error today to userspace (a fix I have submitted back in April). So, this patchset by Thomas is setting max, and, then, if it is a blocking write, tries to evict on a best-effort basis, and returns success after a few attempts, still setting max to the written value. Cascardo.
