On Wed, Mar 25, 2026 at 06:40:40PM +0100, Maarten Lankhorst wrote: > Hey, > > Den 2026-03-23 kl. 18:37, skrev Thadeu Lima de Souza Cascardo: > > On Mon, Mar 23, 2026 at 05:46:28PM +0100, Maarten Lankhorst wrote: > >> Hey, > >> > >> > >> Den 2026-03-21 kl. 20:27, skrev Tejun Heo: > >>> Hello, > >>> > >>> Generally looks okay to me. One comment on 3/3 — the naked xchg() in > >>> set_resource_max() needs a comment explaining why it's used instead of > >>> page_counter_set_max() and what the semantics are (unconditionally sets > >>> max > >>> regardless of current usage to prevent further allocations, since there's > >>> no > >>> eviction mechanism yet). > >>> > >>> Applied 1/3. Maarten, Michal, what do you think? > >> > >> Yeah probably drop 2/3 too since there is no longer a case where setting a > >> limit may fail. > >> > >> Kind regards, > >> ~Maarten Lankhorst > > > > Actually, this can still happen if an invalid region name is given. > > > > So, one could write: > > > > echo -e 'region1 max\ninvalidregion2 max\n' > dmem.max > > > > And even though setting the value for region1 would be applied, the write > > would return -EINVAL. > > Makes sense. It would be good to validate in advance then. If that's not > possible we > should at least not error when we try to update 2 regions simultaneously. > Likely the > best to do so anyway if we want to handle eviction, which may be handled in a > blocking > fashion. > > Kind regards, > ~Maarten Lankhorst
I have submitted only the last patch with the additional comment for now. If it turns out that eviction is handled, you bring up a good point that doing it in a blocking fashion may lead to an underisable effect where setting the max and starting eviction for one region may be delayed by the eviction of a previous region. Is there any reason to keep the support for handling multiple regions in a single write? Thanks. Cascardo.
