Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Nov 12, 2015 at 06:36:20PM +, Mel Gorman wrote: > Bottom line, there is legimate confusion over whether cgroup controllers > are going to be enabled by default or not in the future. If they are > enabled by default, there is a non-zero cost to that and a change in > semantics that

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 11:19:53AM -0500, Johannes Weiner wrote: > On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote: > > On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > > > On Thu, Nov 05, 2015 at 03:40:02PM

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Michal Hocko Date: Fri, 6 Nov 2015 17:46:57 +0100 > On Fri 06-11-15 11:19:53, Johannes Weiner wrote: >> You might think sending these emails is helpful, but it really >> isn't. Not only is it not contributing code, insights, or solutions, >> you're now actively

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: ... > > 3) keep only some (safe) cache types enabled by default with the current > >failing semantic and require an explicit enabling for the complete > >kmem

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > > This would be true if they moved on to the new cgroup API intentionally. > > > The reality is more complicated

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 17:32:51, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 05:28:03PM +0100, Michal Hocko wrote: [...] > > Yes, that part is clear and Johannes made it clear that the kmem tcp > > part is disabled by default. Or are you considering also all the slab > > usage by the networking code

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote: > On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > > > This would be true if they moved on to

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 12:05:55PM +0300, Vladimir Davydov wrote: > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > ... > > > 3) keep only some (safe) cache types enabled by default with the current > > >

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri 06-11-15 11:19:53, Johannes Weiner wrote: > On Fri, Nov 06, 2015 at 11:57:24AM +0100, Michal Hocko wrote: > > On Thu 05-11-15 17:52:00, Johannes Weiner wrote: > > > On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > > > > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 15:55:22, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > On Wed 04-11-15 14:50:37, Johannes Weiner wrote: [...] > > This would be true if they moved on to the new cgroup API intentionally. > > The reality is more complicated though. AFAIK

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Nov 06, 2015 at 05:46:57PM +0100, Michal Hocko wrote: > The basic problem was that the Delegate feature has been backported to > our systemd package without further consideration and that has > invalidated a lot of performance testing because some resource > controllers have measurable

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri 06-11-15 12:05:55, Vladimir Davydov wrote: [...] > If there are no objections, I'll prepare a patch switching to the > white-list approach. Let's start from obvious things like fs_struct, > mm_struct, task_struct, signal_struct, dentry, inode, which can be > easily allocated from user

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Wed 04-11-15 14:50:37, Johannes Weiner wrote: [...] > Because it goes without saying that once the cgroupv2 interface is > released, and people use it in production, there is no way we can then > *add* dentry cache, inode cache, and others to memory.current. That > would be an unacceptable

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 05-11-15 11:16:09, David S. Miller wrote: > From: Michal Hocko > Date: Thu, 5 Nov 2015 15:40:02 +0100 > > > On Wed 04-11-15 14:50:37, Johannes Weiner wrote: > > [...] > >> Because it goes without saying that once the cgroupv2 interface is > >> released, and people use

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Michal Hocko Date: Thu, 5 Nov 2015 15:40:02 +0100 > On Wed 04-11-15 14:50:37, Johannes Weiner wrote: > [...] >> Because it goes without saying that once the cgroupv2 interface is >> released, and people use it in production, there is no way we can then >> *add* dentry

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Michal Hocko Date: Thu, 5 Nov 2015 17:28:03 +0100 > Yes, that part is clear and Johannes made it clear that the kmem tcp > part is disabled by default. Or are you considering also all the slab > usage by the networking code as well? I'm still thinking about the

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Nov 05, 2015 at 03:55:22PM -0500, Johannes Weiner wrote: > On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > > This would be true if they moved on to the new cgroup API intentionally. > > The reality is more complicated though. AFAIK sysmted is waiting for > > cgroup2 already

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Nov 05, 2015 at 05:28:03PM +0100, Michal Hocko wrote: > On Thu 05-11-15 11:16:09, David S. Miller wrote: > > From: Michal Hocko > > Date: Thu, 5 Nov 2015 15:40:02 +0100 > > > > > On Wed 04-11-15 14:50:37, Johannes Weiner wrote: > > > [...] > > >> Because it goes

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Nov 05, 2015 at 03:40:02PM +0100, Michal Hocko wrote: > On Wed 04-11-15 14:50:37, Johannes Weiner wrote: > [...] > > Because it goes without saying that once the cgroupv2 interface is > > released, and people use it in production, there is no way we can then > > *add* dentry cache, inode

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Wed, Nov 04, 2015 at 11:42:40AM +0100, Michal Hocko wrote: > On Thu 29-10-15 09:10:09, Johannes Weiner wrote: > > On Thu, Oct 29, 2015 at 04:25:46PM +0100, Michal Hocko wrote: > > > On Tue 27-10-15 09:42:27, Johannes Weiner wrote: > [...] > > > > You carefully skipped over this part. We can

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 29-10-15 09:10:09, Johannes Weiner wrote: > On Thu, Oct 29, 2015 at 04:25:46PM +0100, Michal Hocko wrote: > > On Tue 27-10-15 09:42:27, Johannes Weiner wrote: [...] > > > You carefully skipped over this part. We can ignore it for socket > > > memory but it's something we need to figure out

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Tue 27-10-15 09:42:27, Johannes Weiner wrote: > On Tue, Oct 27, 2015 at 05:15:54PM +0100, Michal Hocko wrote: > > On Tue 27-10-15 11:41:38, Johannes Weiner wrote: [...] > Or it could be exactly the other way around when you have a workload > that is heavy on filesystem metadata. I don't see why

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Oct 29, 2015 at 04:25:46PM +0100, Michal Hocko wrote: > On Tue 27-10-15 09:42:27, Johannes Weiner wrote: > > On Tue, Oct 27, 2015 at 05:15:54PM +0100, Michal Hocko wrote: > > > On Tue 27-10-15 11:41:38, Johannes Weiner wrote: > > > > IMO that's an implementation detail and a historical

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Michal Hocko Date: Tue, 27 Oct 2015 13:26:47 +0100 > On Mon 26-10-15 12:56:19, Johannes Weiner wrote: > [...] >> Or any other combination of pick-and-choose consumers. But >> honestly, nowadays all our paths are lockless, and the counting is an >> atomic-add-return with

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Mon 26-10-15 12:56:19, Johannes Weiner wrote: [...] > Now you could argue that there might exist specialized workloads that > need to account anonymous pages and page cache, but not socket memory > buffers. Exactly, and there are loads doing this. Memcg groups are also created to limit

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Tue, Oct 27, 2015 at 01:26:47PM +0100, Michal Hocko wrote: > On Mon 26-10-15 12:56:19, Johannes Weiner wrote: > [...] > > Now you could argue that there might exist specialized workloads that > > need to account anonymous pages and page cache, but not socket memory > > buffers. > > Exactly,

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Tue, Oct 27, 2015 at 05:15:54PM +0100, Michal Hocko wrote: > On Tue 27-10-15 11:41:38, Johannes Weiner wrote: > > On Tue, Oct 27, 2015 at 01:26:47PM +0100, Michal Hocko wrote: > > > On Mon 26-10-15 12:56:19, Johannes Weiner wrote: > > > [...] > > > > Now you could argue that there might exist

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Tue 27-10-15 11:41:38, Johannes Weiner wrote: > On Tue, Oct 27, 2015 at 01:26:47PM +0100, Michal Hocko wrote: > > On Mon 26-10-15 12:56:19, Johannes Weiner wrote: > > [...] > > > Now you could argue that there might exist specialized workloads that > > > need to account anonymous pages and page

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Johannes Weiner Date: Tue, 27 Oct 2015 09:42:27 -0700 > On Tue, Oct 27, 2015 at 05:15:54PM +0100, Michal Hocko wrote: >> > For now, something like this as a boot commandline? >> > >> > cgroup.memory=nosocket >> >> That would work for me. > > Okay, then I'll go that

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Tue, Oct 27, 2015 at 05:45:32PM -0700, David Miller wrote: > From: Johannes Weiner > Date: Tue, 27 Oct 2015 09:42:27 -0700 > > > On Tue, Oct 27, 2015 at 05:15:54PM +0100, Michal Hocko wrote: > >> > For now, something like this as a boot commandline? > >> > > >> >

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Fri, Oct 23, 2015 at 06:59:57AM -0700, David Miller wrote: > From: Michal Hocko > Date: Fri, 23 Oct 2015 15:19:56 +0200 > > > On Thu 22-10-15 00:21:33, Johannes Weiner wrote: > >> Socket memory can be a significant share of overall memory consumed by > >> common workloads.

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu 22-10-15 00:21:33, Johannes Weiner wrote: > Socket memory can be a significant share of overall memory consumed by > common workloads. In order to provide reasonable resource isolation > out-of-the-box in the unified hierarchy, this type of memory needs to > be accounted and tracked per

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

From: Michal Hocko Date: Fri, 23 Oct 2015 15:19:56 +0200 > On Thu 22-10-15 00:21:33, Johannes Weiner wrote: >> Socket memory can be a significant share of overall memory consumed by >> common workloads. In order to provide reasonable resource isolation >> out-of-the-box in the

Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy

On Thu, Oct 22, 2015 at 12:21:33AM -0400, Johannes Weiner wrote: ... > @@ -5500,13 +5524,38 @@ void sock_release_memcg(struct sock *sk) > */ > bool mem_cgroup_charge_skmem(struct mem_cgroup *memcg, unsigned int nr_pages) > { > + unsigned int batch = max(CHARGE_BATCH, nr_pages); >