From: Michal Hocko <mhocko@kernel.org> To: Johannes Weiner <hannes@cmpxchg.org> Cc: David Miller <davem@davemloft.net>, akpm@linux-foundation.org, vdavydov@virtuozzo.com, tj@kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy Date: Wed, 4 Nov 2015 11:42:40 +0100 [thread overview] Message-ID: <20151104104239.GG29607@dhcp22.suse.cz> (raw) In-Reply-To: <20151029161009.GA9160@cmpxchg.org> 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 when it comes to slab > > > accounting and tracking. > > > > I am sorry, I didn't mean to skip this part, I though it would be clear > > from the previous text. I think kmem accounting falls into the same > > category. Have a sane default and a global boottime knob to override it > > for those that think differently - for whatever reason they might have. > > Yes, that makes sense to me. > > Like cgroup.memory=nosocket, would you think it makes sense to include > slab in the default for functional/semantical completeness and provide > a cgroup.memory=noslab for powerusers? I am still not sure whether the kmem accounting is stable enough to be enabled by default. If for nothing else the allocation failures, which are not allowed for the global case and easily triggered by the hard limit, might be a big problem. My last attempts to allow GFP_NOFS to fail made me quite skeptical. I still believe this is something which will be solved in the long term but the current state might be still too fragile. So I would rather be conservative and have the kmem accounting disabled by default with a config option and boot parameter to override. If somebody is confident that the desired load is stable then the config can be enabled easily. -- Michal Hocko SUSE Labs
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Johannes Weiner <hannes@cmpxchg.org> Cc: David Miller <davem@davemloft.net>, akpm@linux-foundation.org, vdavydov@virtuozzo.com, tj@kernel.org, netdev@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy Date: Wed, 4 Nov 2015 11:42:40 +0100 [thread overview] Message-ID: <20151104104239.GG29607@dhcp22.suse.cz> (raw) In-Reply-To: <20151029161009.GA9160@cmpxchg.org> 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 when it comes to slab > > > accounting and tracking. > > > > I am sorry, I didn't mean to skip this part, I though it would be clear > > from the previous text. I think kmem accounting falls into the same > > category. Have a sane default and a global boottime knob to override it > > for those that think differently - for whatever reason they might have. > > Yes, that makes sense to me. > > Like cgroup.memory=nosocket, would you think it makes sense to include > slab in the default for functional/semantical completeness and provide > a cgroup.memory=noslab for powerusers? I am still not sure whether the kmem accounting is stable enough to be enabled by default. If for nothing else the allocation failures, which are not allowed for the global case and easily triggered by the hard limit, might be a big problem. My last attempts to allow GFP_NOFS to fail made me quite skeptical. I still believe this is something which will be solved in the long term but the current state might be still too fragile. So I would rather be conservative and have the kmem accounting disabled by default with a config option and boot parameter to override. If somebody is confident that the desired load is stable then the config can be enabled easily. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-11-04 10:42 UTC|newest] Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-10-22 4:21 [PATCH 0/8] mm: memcontrol: account socket memory in unified hierarchy Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-22 4:21 ` [PATCH 1/8] mm: page_counter: let page_counter_try_charge() return bool Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-23 11:31 ` Michal Hocko 2015-10-23 11:31 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 2/8] mm: memcontrol: export root_mem_cgroup Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-23 11:32 ` Michal Hocko 2015-10-23 11:32 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 3/8] net: consolidate memcg socket buffer tracking and accounting Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-22 18:46 ` Vladimir Davydov 2015-10-22 18:46 ` Vladimir Davydov 2015-10-22 18:46 ` Vladimir Davydov 2015-10-22 19:09 ` Johannes Weiner 2015-10-22 19:09 ` Johannes Weiner 2015-10-23 13:42 ` Vladimir Davydov 2015-10-23 13:42 ` Vladimir Davydov 2015-10-23 13:42 ` Vladimir Davydov 2015-10-23 12:38 ` Michal Hocko 2015-10-23 12:38 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 4/8] mm: memcontrol: prepare for unified hierarchy socket accounting Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-23 12:39 ` Michal Hocko 2015-10-23 12:39 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 5/8] mm: memcontrol: account socket memory on unified hierarchy Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-22 18:47 ` Vladimir Davydov 2015-10-22 18:47 ` Vladimir Davydov 2015-10-22 18:47 ` Vladimir Davydov 2015-10-23 13:19 ` Michal Hocko 2015-10-23 13:19 ` Michal Hocko 2015-10-23 13:19 ` Michal Hocko 2015-10-23 13:59 ` David Miller 2015-10-23 13:59 ` David Miller 2015-10-23 13:59 ` David Miller 2015-10-26 16:56 ` Johannes Weiner 2015-10-26 16:56 ` Johannes Weiner 2015-10-27 12:26 ` Michal Hocko 2015-10-27 12:26 ` Michal Hocko 2015-10-27 13:49 ` David Miller 2015-10-27 13:49 ` David Miller 2015-10-27 13:49 ` David Miller 2015-10-27 15:41 ` Johannes Weiner 2015-10-27 15:41 ` Johannes Weiner 2015-10-27 15:41 ` Johannes Weiner 2015-10-27 16:15 ` Michal Hocko 2015-10-27 16:15 ` Michal Hocko 2015-10-27 16:42 ` Johannes Weiner 2015-10-27 16:42 ` Johannes Weiner 2015-10-28 0:45 ` David Miller 2015-10-28 0:45 ` David Miller 2015-10-28 0:45 ` David Miller 2015-10-28 3:05 ` Johannes Weiner 2015-10-28 3:05 ` Johannes Weiner 2015-10-29 15:25 ` Michal Hocko 2015-10-29 15:25 ` Michal Hocko 2015-10-29 16:10 ` Johannes Weiner 2015-10-29 16:10 ` Johannes Weiner 2015-10-29 16:10 ` Johannes Weiner 2015-11-04 10:42 ` Michal Hocko [this message] 2015-11-04 10:42 ` Michal Hocko 2015-11-04 19:50 ` Johannes Weiner 2015-11-04 19:50 ` Johannes Weiner 2015-11-04 19:50 ` Johannes Weiner 2015-11-05 14:40 ` Michal Hocko 2015-11-05 14:40 ` Michal Hocko 2015-11-05 16:16 ` David Miller 2015-11-05 16:16 ` David Miller 2015-11-05 16:28 ` Michal Hocko 2015-11-05 16:28 ` Michal Hocko 2015-11-05 16:28 ` Michal Hocko 2015-11-05 16:30 ` David Miller 2015-11-05 16:30 ` David Miller 2015-11-05 22:32 ` Johannes Weiner 2015-11-05 22:32 ` Johannes Weiner 2015-11-05 22:32 ` Johannes Weiner 2015-11-06 12:51 ` Michal Hocko 2015-11-06 12:51 ` Michal Hocko 2015-11-05 20:55 ` Johannes Weiner 2015-11-05 20:55 ` Johannes Weiner 2015-11-05 22:52 ` Johannes Weiner 2015-11-05 22:52 ` Johannes Weiner 2015-11-05 22:52 ` Johannes Weiner 2015-11-06 10:57 ` Michal Hocko 2015-11-06 10:57 ` Michal Hocko 2015-11-06 16:19 ` Johannes Weiner 2015-11-06 16:19 ` Johannes Weiner 2015-11-06 16:46 ` Michal Hocko 2015-11-06 16:46 ` Michal Hocko 2015-11-06 16:46 ` Michal Hocko 2015-11-06 17:45 ` Johannes Weiner 2015-11-06 17:45 ` Johannes Weiner 2015-11-06 17:45 ` Johannes Weiner 2015-11-07 3:45 ` David Miller 2015-11-07 3:45 ` David Miller 2015-11-12 18:36 ` Mel Gorman 2015-11-12 18:36 ` Mel Gorman 2015-11-12 18:36 ` Mel Gorman 2015-11-12 19:12 ` Johannes Weiner 2015-11-12 19:12 ` Johannes Weiner 2015-11-06 9:05 ` Vladimir Davydov 2015-11-06 9:05 ` Vladimir Davydov 2015-11-06 9:05 ` Vladimir Davydov 2015-11-06 9:05 ` Vladimir Davydov 2015-11-06 13:29 ` Michal Hocko 2015-11-06 13:29 ` Michal Hocko 2015-11-06 16:35 ` Johannes Weiner 2015-11-06 16:35 ` Johannes Weiner 2015-11-06 13:21 ` Michal Hocko 2015-11-06 13:21 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 6/8] mm: vmscan: simplify memcg vs. global shrinker invocation Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-23 13:26 ` Michal Hocko 2015-10-23 13:26 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 7/8] mm: vmscan: report vmpressure at the level of reclaim activity Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-22 18:48 ` Vladimir Davydov 2015-10-22 18:48 ` Vladimir Davydov 2015-10-22 18:48 ` Vladimir Davydov 2015-10-22 18:48 ` Vladimir Davydov 2015-10-23 13:49 ` Michal Hocko 2015-10-23 13:49 ` Michal Hocko 2015-10-23 13:49 ` Michal Hocko 2015-10-22 4:21 ` [PATCH 8/8] mm: memcontrol: hook up vmpressure to socket pressure Johannes Weiner 2015-10-22 4:21 ` Johannes Weiner 2015-10-22 18:57 ` Vladimir Davydov 2015-10-22 18:57 ` Vladimir Davydov 2015-10-22 18:57 ` Vladimir Davydov 2015-10-22 18:45 ` [PATCH 0/8] mm: memcontrol: account socket memory in unified hierarchy Vladimir Davydov 2015-10-22 18:45 ` Vladimir Davydov 2015-10-22 18:45 ` Vladimir Davydov 2015-10-26 17:22 ` Johannes Weiner 2015-10-26 17:22 ` Johannes Weiner 2015-10-26 17:22 ` Johannes Weiner 2015-10-26 17:22 ` Johannes Weiner 2015-10-27 8:43 ` Vladimir Davydov 2015-10-27 8:43 ` Vladimir Davydov 2015-10-27 8:43 ` Vladimir Davydov 2015-10-27 16:01 ` Johannes Weiner 2015-10-27 16:01 ` Johannes Weiner 2015-10-28 8:20 ` Vladimir Davydov 2015-10-28 8:20 ` Vladimir Davydov 2015-10-28 8:20 ` Vladimir Davydov 2015-10-28 18:58 ` Johannes Weiner 2015-10-28 18:58 ` Johannes Weiner 2015-10-29 9:27 ` Vladimir Davydov 2015-10-29 9:27 ` Vladimir Davydov 2015-10-29 9:27 ` Vladimir Davydov 2015-10-29 17:52 ` Johannes Weiner 2015-10-29 17:52 ` Johannes Weiner 2015-10-29 17:52 ` Johannes Weiner 2015-11-02 14:47 ` Vladimir Davydov 2015-11-02 14:47 ` Vladimir Davydov 2015-11-02 14:47 ` Vladimir Davydov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151104104239.GG29607@dhcp22.suse.cz \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=cgroups@vger.kernel.org \ --cc=davem@davemloft.net \ --cc=hannes@cmpxchg.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=netdev@vger.kernel.org \ --cc=tj@kernel.org \ --cc=vdavydov@virtuozzo.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.