From: Tejun Heo <tj@kernel.org> To: Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org>, Hugh Dickins <hughd@google.com>, Andrew Morton <akpm@linux-foundation.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Greg Thelen <gthelen@google.com>, Michel Lespinasse <walken@google.com>, Roman Gushchin <klamm@yandex-team.ru>, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org Subject: Re: [PATCH 2/2] memcg: Allow hard guarantee mode for low limit reclaim Date: Mon, 9 Jun 2014 09:54:41 -0400 [thread overview] Message-ID: <20140609135441.GA22540@htj.dyndns.org> (raw) In-Reply-To: <20140609083042.GB7144@dhcp22.suse.cz> Hello, On Mon, Jun 09, 2014 at 10:30:42AM +0200, Michal Hocko wrote: > On Fri 06-06-14 11:29:14, Tejun Heo wrote: > > Why is this necessary? > > It allows user/admin to set the default behavior. By recomipling the kernel for something which can be trivially configured post-boot without any difference? The only thing it'll achieve is confusing the hell out of people why different kernels show different behaviors without any userland differences while taxing the already constrained kernel configuration process more for no gain whatsoever. > How do you propose to tell the default then? Only at the runtime? > I really do not insist on the kconfig. I find it useful for a) > documentation purpose b) easy way to configure the default. Please don't ever add Kconfig options like this. This is uttrely unnecessary and idiotic. You don't add completely redundant Kconfig option for documentation purposes. > > * Are you sure soft and hard guarantees aren't useful when used in > > combination? If so, why would that be the case? > > This was a call from Google to have per-memcg setup AFAIR. Using > different reclaim protection on the global case vs. limit reclaim makes > a lot of sense to me. If this is a major obstacle then I am OK to drop > it and only have a global setting for now. Isn't it obvious that what needs to be investigated is why we're trying to add an interface which is completely different for guarantees as compared to limits? Why wouldn't they have a symmetric interface in the reverse direction as soft/hard limits? If not, where does the asymmetry come from? Thse are the *first* questions which should come to anyone's mind when [s]he is trying to add configs for a different type of threshholds and something which must be explicitly laid out as rationales for the design choices. > > * We have pressure monitoring interface which can be used for soft > > limit pressure monitoring. > > Which one is that? I only know about oom_control triggered by the hard > limit pressure. Weren't you guys planning to use vmpressre notification to find out about softlimit breach conditions? > > How should breaching soft guarantee be > > factored into that? There doesn't seem to be any way of notifying > > that at the moment? Wouldn't we want that to be integrated into the > > same mechanism? > > Yes, there is. We have a counter in memory.stat file which tells how > many times the limit has been breached. How does the userland find out? By polling the file every frigging second? Note that there actually is an actual asymmetry here which makes breaching soft guarantee a much more significant event than breaching soft limit - the former is violation of the configured objective, the latter is not. You *need* a way to notify the event. > > What scares me the most is that you don't even seem to have noticed > > the asymmetry and are proposing userland-facing interface without > > actually thinking things through. This is exactly how we've been > > getting into trouble. > > This has been discussed up and down for the last _two_ years. I have > considered other options how to provide a very _useful_ feature users > are calling for. There is even general consensus among developers that AFAIR, there hasn't been much discussion about the details of the interface and the proposed one is almost laughable. How is this acceptable as a userland visible API that we need to maintain for the future? It's broken on delivery. > the feature is desirable and that the two modes (soft/hard) memory > protection are needed. Yet I would _really_ like to hear any > suggestion to get unstuck. It is far from useful to come and Nack this > _again_ without providing any alternative suggestions. I've pointed out two major points where the proposed interface is evidently deficient and told you why they're so and it's not like the said deficiencies are anything subtle. If you can't figure out what to do next from there on, I don't think I can help you. Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org> To: Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org>, Hugh Dickins <hughd@google.com>, Andrew Morton <akpm@linux-foundation.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>, Greg Thelen <gthelen@google.com>, Michel Lespinasse <walken@google.com>, Roman Gushchin <klamm@yandex-team.ru>, LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org Subject: Re: [PATCH 2/2] memcg: Allow hard guarantee mode for low limit reclaim Date: Mon, 9 Jun 2014 09:54:41 -0400 [thread overview] Message-ID: <20140609135441.GA22540@htj.dyndns.org> (raw) In-Reply-To: <20140609083042.GB7144@dhcp22.suse.cz> Hello, On Mon, Jun 09, 2014 at 10:30:42AM +0200, Michal Hocko wrote: > On Fri 06-06-14 11:29:14, Tejun Heo wrote: > > Why is this necessary? > > It allows user/admin to set the default behavior. By recomipling the kernel for something which can be trivially configured post-boot without any difference? The only thing it'll achieve is confusing the hell out of people why different kernels show different behaviors without any userland differences while taxing the already constrained kernel configuration process more for no gain whatsoever. > How do you propose to tell the default then? Only at the runtime? > I really do not insist on the kconfig. I find it useful for a) > documentation purpose b) easy way to configure the default. Please don't ever add Kconfig options like this. This is uttrely unnecessary and idiotic. You don't add completely redundant Kconfig option for documentation purposes. > > * Are you sure soft and hard guarantees aren't useful when used in > > combination? If so, why would that be the case? > > This was a call from Google to have per-memcg setup AFAIR. Using > different reclaim protection on the global case vs. limit reclaim makes > a lot of sense to me. If this is a major obstacle then I am OK to drop > it and only have a global setting for now. Isn't it obvious that what needs to be investigated is why we're trying to add an interface which is completely different for guarantees as compared to limits? Why wouldn't they have a symmetric interface in the reverse direction as soft/hard limits? If not, where does the asymmetry come from? Thse are the *first* questions which should come to anyone's mind when [s]he is trying to add configs for a different type of threshholds and something which must be explicitly laid out as rationales for the design choices. > > * We have pressure monitoring interface which can be used for soft > > limit pressure monitoring. > > Which one is that? I only know about oom_control triggered by the hard > limit pressure. Weren't you guys planning to use vmpressre notification to find out about softlimit breach conditions? > > How should breaching soft guarantee be > > factored into that? There doesn't seem to be any way of notifying > > that at the moment? Wouldn't we want that to be integrated into the > > same mechanism? > > Yes, there is. We have a counter in memory.stat file which tells how > many times the limit has been breached. How does the userland find out? By polling the file every frigging second? Note that there actually is an actual asymmetry here which makes breaching soft guarantee a much more significant event than breaching soft limit - the former is violation of the configured objective, the latter is not. You *need* a way to notify the event. > > What scares me the most is that you don't even seem to have noticed > > the asymmetry and are proposing userland-facing interface without > > actually thinking things through. This is exactly how we've been > > getting into trouble. > > This has been discussed up and down for the last _two_ years. I have > considered other options how to provide a very _useful_ feature users > are calling for. There is even general consensus among developers that AFAIR, there hasn't been much discussion about the details of the interface and the proposed one is almost laughable. How is this acceptable as a userland visible API that we need to maintain for the future? It's broken on delivery. > the feature is desirable and that the two modes (soft/hard) memory > protection are needed. Yet I would _really_ like to hear any > suggestion to get unstuck. It is far from useful to come and Nack this > _again_ without providing any alternative suggestions. I've pointed out two major points where the proposed interface is evidently deficient and told you why they're so and it's not like the said deficiencies are anything subtle. If you can't figure out what to do next from there on, I don't think I can help you. Thanks. -- tejun -- 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:[~2014-06-09 13:54 UTC|newest] Thread overview: 196+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-04-28 12:26 [PATCH v2 0/4] memcg: Low-limit reclaim Michal Hocko 2014-04-28 12:26 ` Michal Hocko 2014-04-28 12:26 ` [PATCH 1/4] memcg, mm: introduce lowlimit reclaim Michal Hocko 2014-04-28 12:26 ` Michal Hocko 2014-04-30 22:55 ` Johannes Weiner 2014-04-30 22:55 ` Johannes Weiner 2014-05-02 9:36 ` Michal Hocko 2014-05-02 9:36 ` Michal Hocko 2014-05-02 12:07 ` Michal Hocko 2014-05-02 12:07 ` Michal Hocko 2014-05-02 13:01 ` Johannes Weiner 2014-05-02 13:01 ` Johannes Weiner 2014-05-02 14:15 ` Michal Hocko 2014-05-02 14:15 ` Michal Hocko 2014-05-02 15:04 ` Johannes Weiner 2014-05-02 15:04 ` Johannes Weiner 2014-05-02 15:11 ` Michal Hocko 2014-05-02 15:11 ` Michal Hocko 2014-05-02 15:34 ` Johannes Weiner 2014-05-02 15:34 ` Johannes Weiner 2014-05-02 15:48 ` Michal Hocko 2014-05-02 15:48 ` Michal Hocko 2014-05-06 19:58 ` Michal Hocko 2014-05-06 19:58 ` Michal Hocko 2014-05-02 15:58 ` Johannes Weiner 2014-05-02 15:58 ` Johannes Weiner 2014-05-02 16:49 ` Michal Hocko 2014-05-02 16:49 ` Michal Hocko 2014-05-02 22:00 ` Johannes Weiner 2014-05-02 22:00 ` Johannes Weiner 2014-05-05 14:21 ` Michal Hocko 2014-05-05 14:21 ` Michal Hocko 2014-05-19 16:18 ` Michal Hocko 2014-05-19 16:18 ` Michal Hocko 2014-06-11 15:15 ` Johannes Weiner 2014-06-11 15:15 ` Johannes Weiner 2014-06-11 16:08 ` Michal Hocko 2014-06-11 16:08 ` Michal Hocko 2014-05-06 13:29 ` Johannes Weiner 2014-05-06 14:32 ` Michal Hocko 2014-05-06 14:32 ` Michal Hocko 2014-05-06 15:21 ` Johannes Weiner 2014-05-06 15:21 ` Johannes Weiner 2014-05-06 16:12 ` Michal Hocko 2014-05-06 16:12 ` Michal Hocko 2014-05-06 16:51 ` Johannes Weiner 2014-05-06 16:51 ` Johannes Weiner 2014-05-06 18:30 ` Michal Hocko 2014-05-06 18:30 ` Michal Hocko 2014-05-06 19:55 ` Johannes Weiner 2014-05-06 19:55 ` Johannes Weiner 2014-04-28 12:26 ` [PATCH 2/4] memcg: Allow setting low_limit Michal Hocko 2014-04-28 12:26 ` Michal Hocko 2014-04-28 12:26 ` [PATCH 3/4] memcg, doc: clarify global vs. limit reclaims Michal Hocko 2014-04-28 12:26 ` Michal Hocko 2014-04-30 23:03 ` Johannes Weiner 2014-04-30 23:03 ` Johannes Weiner 2014-05-02 9:43 ` Michal Hocko 2014-05-02 9:43 ` Michal Hocko 2014-05-06 19:56 ` Michal Hocko 2014-05-06 19:56 ` Michal Hocko 2014-04-28 12:26 ` [PATCH 4/4] memcg: Document memory.low_limit_in_bytes Michal Hocko 2014-04-28 12:26 ` Michal Hocko 2014-04-30 22:57 ` Johannes Weiner 2014-04-30 22:57 ` Johannes Weiner 2014-05-02 9:46 ` Michal Hocko 2014-05-02 9:46 ` Michal Hocko 2014-04-28 15:46 ` [PATCH v2 0/4] memcg: Low-limit reclaim Roman Gushchin 2014-04-28 15:46 ` Roman Gushchin 2014-04-29 7:42 ` Greg Thelen 2014-04-29 7:42 ` Greg Thelen 2014-04-29 10:50 ` Roman Gushchin 2014-04-29 10:50 ` Roman Gushchin 2014-04-29 12:54 ` Michal Hocko 2014-04-29 12:54 ` Michal Hocko 2014-04-30 21:52 ` Andrew Morton 2014-04-30 21:52 ` Andrew Morton 2014-04-30 22:49 ` Johannes Weiner 2014-04-30 22:49 ` Johannes Weiner 2014-05-02 12:03 ` Michal Hocko 2014-05-02 12:03 ` Michal Hocko 2014-04-30 21:59 ` Andrew Morton 2014-04-30 21:59 ` Andrew Morton 2014-05-02 11:22 ` Michal Hocko 2014-05-02 11:22 ` Michal Hocko 2014-05-28 12:10 ` Michal Hocko 2014-05-28 12:10 ` Michal Hocko 2014-05-28 13:49 ` Johannes Weiner 2014-05-28 13:49 ` Johannes Weiner 2014-05-28 14:21 ` Michal Hocko 2014-05-28 14:21 ` Michal Hocko 2014-05-28 15:28 ` Johannes Weiner 2014-05-28 15:28 ` Johannes Weiner 2014-05-28 15:54 ` Michal Hocko 2014-05-28 15:54 ` Michal Hocko 2014-05-28 16:33 ` Johannes Weiner 2014-05-28 16:33 ` Johannes Weiner 2014-06-03 11:07 ` Michal Hocko 2014-06-03 11:07 ` Michal Hocko 2014-06-03 14:22 ` Johannes Weiner 2014-06-03 14:22 ` Johannes Weiner 2014-06-04 14:46 ` Michal Hocko 2014-06-04 14:46 ` Michal Hocko 2014-06-04 15:44 ` Johannes Weiner 2014-06-04 15:44 ` Johannes Weiner 2014-06-04 19:18 ` Hugh Dickins 2014-06-04 19:18 ` Hugh Dickins 2014-06-04 21:45 ` Johannes Weiner 2014-06-04 21:45 ` Johannes Weiner 2014-06-05 14:51 ` Michal Hocko 2014-06-05 14:51 ` Michal Hocko 2014-06-05 16:10 ` Johannes Weiner 2014-06-05 16:10 ` Johannes Weiner 2014-06-05 16:43 ` Michal Hocko 2014-06-05 16:43 ` Michal Hocko 2014-06-05 18:23 ` Johannes Weiner 2014-06-05 18:23 ` Johannes Weiner 2014-06-06 14:44 ` Michal Hocko 2014-06-06 14:44 ` Michal Hocko 2014-06-06 14:46 ` [PATCH 1/2] mm, memcg: allow OOM if no memcg is eligible during direct reclaim Michal Hocko 2014-06-06 14:46 ` Michal Hocko 2014-06-06 14:46 ` [PATCH 2/2] memcg: Allow hard guarantee mode for low limit reclaim Michal Hocko 2014-06-06 14:46 ` Michal Hocko 2014-06-06 15:29 ` Tejun Heo 2014-06-06 15:29 ` Tejun Heo 2014-06-06 15:34 ` Tejun Heo 2014-06-06 15:34 ` Tejun Heo 2014-06-09 8:30 ` Michal Hocko 2014-06-09 8:30 ` Michal Hocko 2014-06-09 13:54 ` Tejun Heo [this message] 2014-06-09 13:54 ` Tejun Heo 2014-06-09 22:52 ` Greg Thelen 2014-06-09 22:52 ` Greg Thelen 2014-06-10 16:57 ` Johannes Weiner 2014-06-10 16:57 ` Johannes Weiner 2014-06-10 22:16 ` Greg Thelen 2014-06-10 22:16 ` Greg Thelen 2014-06-11 7:57 ` Michal Hocko 2014-06-11 7:57 ` Michal Hocko 2014-06-11 8:00 ` [PATCH 1/2] mm, memcg: allow OOM if no memcg is eligible during direct reclaim Michal Hocko 2014-06-11 8:00 ` Michal Hocko 2014-06-11 8:00 ` [PATCH 2/2] memcg: Allow guarantee reclaim Michal Hocko 2014-06-11 8:00 ` Michal Hocko 2014-06-11 15:36 ` Johannes Weiner 2014-06-11 15:36 ` Johannes Weiner 2014-06-12 13:22 ` Michal Hocko 2014-06-12 13:22 ` Michal Hocko 2014-06-12 13:56 ` Johannes Weiner 2014-06-12 13:56 ` Johannes Weiner 2014-06-12 14:22 ` Michal Hocko 2014-06-12 14:22 ` Michal Hocko 2014-06-12 16:17 ` Tejun Heo 2014-06-12 16:17 ` Tejun Heo 2014-06-16 12:59 ` Michal Hocko 2014-06-16 12:59 ` Michal Hocko 2014-06-16 13:57 ` Tejun Heo 2014-06-16 13:57 ` Tejun Heo 2014-06-16 14:04 ` Michal Hocko 2014-06-16 14:04 ` Michal Hocko 2014-06-16 14:12 ` Tejun Heo 2014-06-16 14:12 ` Tejun Heo 2014-06-16 14:29 ` Michal Hocko 2014-06-16 14:29 ` Michal Hocko 2014-06-16 14:40 ` Tejun Heo 2014-06-16 14:40 ` Tejun Heo 2014-06-12 16:51 ` Johannes Weiner 2014-06-12 16:51 ` Johannes Weiner 2014-06-16 13:22 ` Michal Hocko 2014-06-16 13:22 ` Michal Hocko 2014-06-11 15:20 ` [PATCH 1/2] mm, memcg: allow OOM if no memcg is eligible during direct reclaim Johannes Weiner 2014-06-11 15:20 ` Johannes Weiner 2014-06-11 16:14 ` Michal Hocko 2014-06-11 16:14 ` Michal Hocko 2014-06-11 12:31 ` [PATCH 2/2] memcg: Allow hard guarantee mode for low limit reclaim Tejun Heo 2014-06-11 12:31 ` Tejun Heo 2014-06-11 14:11 ` Michal Hocko 2014-06-11 14:11 ` Michal Hocko 2014-06-11 15:34 ` Tejun Heo 2014-06-11 15:34 ` Tejun Heo 2014-06-05 19:36 ` [PATCH v2 0/4] memcg: Low-limit reclaim Tejun Heo 2014-06-05 19:36 ` Tejun Heo 2014-06-05 14:32 ` Michal Hocko 2014-06-05 14:32 ` Michal Hocko 2014-06-05 15:43 ` Johannes Weiner 2014-06-05 15:43 ` Johannes Weiner 2014-06-05 16:09 ` Michal Hocko 2014-06-05 16:09 ` Michal Hocko 2014-06-05 16:46 ` Johannes Weiner 2014-06-05 16:46 ` Johannes Weiner 2014-05-28 16:17 ` Greg Thelen 2014-05-28 16:17 ` Greg Thelen 2014-06-03 11:09 ` Michal Hocko 2014-06-03 11:09 ` Michal Hocko 2014-06-03 14:01 ` Greg Thelen 2014-06-03 14:44 ` Michal Hocko 2014-06-03 14:44 ` Michal Hocko
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=20140609135441.GA22540@htj.dyndns.org \ --to=tj@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=gthelen@google.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=klamm@yandex-team.ru \ --cc=kosaki.motohiro@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.cz \ --cc=walken@google.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.