On Wed 29-06-22 19:08:42, Yosry Ahmed wrote: > On Wed, Jun 29, 2022 at 6:07 PM Shakeel Butt <shakeelb@xxxxxxxxxx> wrote: > > > > On Mon, Jun 27, 2022 at 10:04 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > > > > > On Mon, Jun 27, 2022 at 5:31 AM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > [...] > > > > > > > > I can see clear arguments for memory.reclaim opt out for vmpressure > > > > because we have established that this is not a measure to express a > > > > memory pressure on the cgroup. > > > > > > > > Max/High are less clear to me, TBH. I do understand reasoning for PSI > > > > exclusion because considering the calling process to be stalled and > > > > non-productive is misleading. It just does its work so in a way it is > > > > a productive time in the end. For the vmpressure, which measures how > > > > hard/easy it is to reclaim memory why this should special for this > > > > particular reclaim? > > > > > > > > Again, an explanation of the effect on the socket pressure could give a > > > > better picture. Say that I somebody reduces the limit (hard/high) and it > > > > takes quite some effort to shrink the consumption down. Should the > > > > networking layer react to that in any way or should it wait for the > > > > active allocation during that process to find that out? > > > > > > I am out of my depth here. Any answer on my side would be purely > > > speculation at this point. Shakeel, can you help us here or tag some > > > networking people? > > > > So, the effect of returning true from mem_cgroup_under_socket_pressure() are: > > > > 1. Reducing send and receive buffers of the current socket. > > 2. May drop packets on the rx path. > > 3. May throttle current thread on the tx path. > > > > Now regarding the behavior from the reclaim due to reducing max or > > high, I think the kernel should not ignore vmpressure. Please note > > that unlike PSI which is associated with the current process, > > vmpressure is associated with the target memcg. So, any reclaim on > > that memcg due to real shortage of memory should not be ignored. That > > reclaim can be global reclaim or limit reclaim of ancestor or itself > > or reclaim due to lowering the limit of ancestor or itself. > > So it seems like we should only ignore vmpressure for proactive > reclaim (aka memory.reclaim). > > Michal, let me know what you think here, I can drop psi and > limit-setting changes in v3 and basically just ignore vmpressure for > memory.reclaim (MEMCG_RECLAIM_PROACTIVE / sc->proactive instead of > MEMCG_RECLAIM_CONTROLLED / sc->controlled maybe). Yes, that makes much more sense to me. -- Michal Hocko SUSE Labs
