Messages in this thread | | | Date | Fri, 16 Jun 2023 15:27:24 +0800 | Subject | Re: [RFC PATCH net-next] sock: Propose socket.urgent for sockmem isolation | From | Abel Wu <> |
| |
Gentle ping :)
Any suggestions for memory over-committed scenario?
Thanks, Abel
On 6/13/23 2:46 PM, Abel Wu wrote: > On 6/9/23 5:07 PM, Eric Dumazet wrote: >> On Fri, Jun 9, 2023 at 10:28 AM Abel Wu <wuyun.abel@bytedance.com> wrote: >>> >>> This is just a PoC patch intended to resume the discussion about >>> tcpmem isolation opened by Google in LPC'22 [1]. >>> >>> We are facing the same problem that the global shared threshold can >>> cause isolation issues. Low priority jobs can hog TCP memory and >>> adversely impact higher priority jobs. What's worse is that these >>> low priority jobs usually have smaller cpu weights leading to poor >>> ability to consume rx data. >>> >>> To tackle this problem, an interface for non-root cgroup memory >>> controller named 'socket.urgent' is proposed. It determines whether >>> the sockets of this cgroup and its descendants can escape from the >>> constrains or not under global socket memory pressure. >>> >>> The 'urgent' semantics will not take effect under memcg pressure in >>> order to protect against worse memstalls, thus will be the same as >>> before without this patch. >>> >>> This proposal doesn't remove protocal's threshold as we found it >>> useful in restraining memory defragment. As aforementioned the low >>> priority jobs can hog lots of memory, which is unreclaimable and >>> unmovable, for some time due to small cpu weight. >>> >>> So in practice we allow high priority jobs with net-memcg accounting >>> enabled to escape the global constrains if the net-memcg itselt is >>> not under pressure. While for lower priority jobs, the budget will >>> be tightened as the memory usage of 'urgent' jobs increases. In this >>> way we can finally achieve: >>> >>> - Important jobs won't be priority inversed by the background >>> jobs in terms of socket memory pressure/limit. >>> >>> - Global constrains are still effective, but only on non-urgent >>> jobs, useful for admins on policy decision on defrag. >>> >>> Comments/Ideas are welcomed, thanks! >>> >> >> This seems to go in a complete opposite direction than memcg promises. >> >> Can we fix memcg, so that : >> >> Each group can use the memory it was provisioned (this includes TCP >> buffers) > > Yes, but might not be easy once memory gets over-committed (which is > common in modern data-centers). So as a tradeoff, we intend to put > harder constraint on memory allocation for low priority jobs. Or else > if every job can use its provisioned memory, than there will be more > memstalls blocking random jobs which could be the important ones. > Either way hurts performance, but the difference is whose performance > gets hurt. > > Memory protection (memory.{min,low}) helps the important jobs less > affected by memstalls. But once low priority jobs use lots of kernel > memory like sockmem, the protection might become much less efficient. > >> >> Global tcp_memory can disappear (set tcp_mem to infinity)
| |