From: Tejun Heo <tj@kernel.org> To: Michal Hocko <mhocko@suse.cz> Cc: Glauber Costa <glommer@parallels.com>, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal <suleiman@google.com>, Frederic Weisbecker <fweisbec@gmail.com>, Mel Gorman <mgorman@suse.de>, David Rientjes <rientjes@google.com>, Johannes Weiner <hannes@cmpxchg.org> Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Date: Sun, 30 Sep 2012 17:47:50 +0900 [thread overview] Message-ID: <20120930084750.GI10383@mtj.dyndns.org> (raw) In-Reply-To: <20120927150950.GG29104@dhcp22.suse.cz> Hello, Michal. On Thu, Sep 27, 2012 at 05:09:50PM +0200, Michal Hocko wrote: > On Thu 27-09-12 07:33:00, Tejun Heo wrote: > > I'm not too convinced. First of all, the overhead added by kmemcg > > isn't big. > > You are probably talking about memory overhead which is indeed not that > big (except for possible side effects as fragmentation which you mention > bellow). But the runtime overhead is present, as far as I understand from > what Glauber said. But, on the other hand, it is fair to say that those > who _want_ use the feature should pay for it. Yeah, as long as the overhead is reasonable and it doesn't affect non-users, I think we should put more emphasis on simplicity. cgroup is pretty hairy (from both implementation and interface POVs) to begin with. Unfortunately, what's reasonable or how much more emphasis varies widely depending on who one asks. > > The hot path overhead is quite minimal - it doesn't do much more than > > indirecting one more time. In terms of memory usage, it sure could > > lead to a bit more fragmentation but even if it gets to several megs > > per cgroup, I don't think that's something excessive. So, there is > > overhead but I don't believe it to be prohibitive. > > Remember that users do not want to pay even "something minimal" when the > feature is not needed. Yeah but, if we can get it down to, say, around 1% under most workloads for memcg users, it is quite questionable to introduce full hierarchical configuration to allow avoiding that, isn't it? > > The distinction between "trusted" and "untrusted" is something > > artificially created due to the assumed deficiency of kmemcg > > implementation. > > Not really. It doesn't have to do anything with the overhead (be it > memory or runtime). It really boils down to "do I need/want it at all". > Why would I want to think about how much kernel memory is in use in the > first place? Or do you think that user memory accounting should be > deprecated? But you can apply the same "do I need/want it at all" question to the configuration parameter too. I can see your point but the decision seems muddy to me, and if muddy, I prefer to err on the side of being too conservative. > > This is userland visible API. > > I am not sure which API visible part you have in mind but > kmem.limit_in_bytes will be there whether we go with global knob or "no > limit no accounting" approach. I mean full hierarchical configuration of it. It becomes something which each memcg user cares about instead of something which the base system / admin flips on system boot. > > We can always expand the flexibility. Let's do the simple thing > > first. As an added bonus, it would enable using static_keys for > > accounting branches too. > > While I do agree with you in general and being careful is at place in > this area as time shown several times, this seems to be too restrictive > in this particular case. > We won't save almost no code with the global knob so I am not sure > what we are actually saving here. Global knob will just give us all or > nothing semantic without making the whole thing simpler. You will stick > with static branches and checkes whether the group accountable anyway, > right? The thing is about the same argument can be made about .use_hierarchy too. It doesn't necessarily make the code much harier. Especially because the code is structured with that feature on mind, removing .use_hierarchy might not remove whole lot of code; however, the wider range of behavior which got exposed through that poses a much larger problem when we try to make modifications on related behaviors. We get a lot more locked down by seemingly not too much code and our long term maintainability / sustainability suffers as a result. I'm not trying to say this is as bad as .use_hierarchy but want to point out that memcg and cgroup in general have had pretty strong tendency to choose overly flexible and complex designs and interfaces and it's probably about time we become more careful especially about stuff which is visible to userland. Thanks. -- tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org> To: Michal Hocko <mhocko@suse.cz> Cc: Glauber Costa <glommer@parallels.com>, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, devel@openvz.org, linux-mm@kvack.org, Suleiman Souhlal <suleiman@google.com>, Frederic Weisbecker <fweisbec@gmail.com>, Mel Gorman <mgorman@suse.de>, David Rientjes <rientjes@google.com>, Johannes Weiner <hannes@cmpxchg.org> Subject: Re: [PATCH v3 04/13] kmem accounting basic infrastructure Date: Sun, 30 Sep 2012 17:47:50 +0900 [thread overview] Message-ID: <20120930084750.GI10383@mtj.dyndns.org> (raw) In-Reply-To: <20120927150950.GG29104@dhcp22.suse.cz> Hello, Michal. On Thu, Sep 27, 2012 at 05:09:50PM +0200, Michal Hocko wrote: > On Thu 27-09-12 07:33:00, Tejun Heo wrote: > > I'm not too convinced. First of all, the overhead added by kmemcg > > isn't big. > > You are probably talking about memory overhead which is indeed not that > big (except for possible side effects as fragmentation which you mention > bellow). But the runtime overhead is present, as far as I understand from > what Glauber said. But, on the other hand, it is fair to say that those > who _want_ use the feature should pay for it. Yeah, as long as the overhead is reasonable and it doesn't affect non-users, I think we should put more emphasis on simplicity. cgroup is pretty hairy (from both implementation and interface POVs) to begin with. Unfortunately, what's reasonable or how much more emphasis varies widely depending on who one asks. > > The hot path overhead is quite minimal - it doesn't do much more than > > indirecting one more time. In terms of memory usage, it sure could > > lead to a bit more fragmentation but even if it gets to several megs > > per cgroup, I don't think that's something excessive. So, there is > > overhead but I don't believe it to be prohibitive. > > Remember that users do not want to pay even "something minimal" when the > feature is not needed. Yeah but, if we can get it down to, say, around 1% under most workloads for memcg users, it is quite questionable to introduce full hierarchical configuration to allow avoiding that, isn't it? > > The distinction between "trusted" and "untrusted" is something > > artificially created due to the assumed deficiency of kmemcg > > implementation. > > Not really. It doesn't have to do anything with the overhead (be it > memory or runtime). It really boils down to "do I need/want it at all". > Why would I want to think about how much kernel memory is in use in the > first place? Or do you think that user memory accounting should be > deprecated? But you can apply the same "do I need/want it at all" question to the configuration parameter too. I can see your point but the decision seems muddy to me, and if muddy, I prefer to err on the side of being too conservative. > > This is userland visible API. > > I am not sure which API visible part you have in mind but > kmem.limit_in_bytes will be there whether we go with global knob or "no > limit no accounting" approach. I mean full hierarchical configuration of it. It becomes something which each memcg user cares about instead of something which the base system / admin flips on system boot. > > We can always expand the flexibility. Let's do the simple thing > > first. As an added bonus, it would enable using static_keys for > > accounting branches too. > > While I do agree with you in general and being careful is at place in > this area as time shown several times, this seems to be too restrictive > in this particular case. > We won't save almost no code with the global knob so I am not sure > what we are actually saving here. Global knob will just give us all or > nothing semantic without making the whole thing simpler. You will stick > with static branches and checkes whether the group accountable anyway, > right? The thing is about the same argument can be made about .use_hierarchy too. It doesn't necessarily make the code much harier. Especially because the code is structured with that feature on mind, removing .use_hierarchy might not remove whole lot of code; however, the wider range of behavior which got exposed through that poses a much larger problem when we try to make modifications on related behaviors. We get a lot more locked down by seemingly not too much code and our long term maintainability / sustainability suffers as a result. I'm not trying to say this is as bad as .use_hierarchy but want to point out that memcg and cgroup in general have had pretty strong tendency to choose overly flexible and complex designs and interfaces and it's probably about time we become more careful especially about stuff which is visible to userland. 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:[~2012-09-30 8:48 UTC|newest] Thread overview: 323+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-09-18 14:03 [PATCH v3 00/13] kmem controller for memcg Glauber Costa 2012-09-18 14:03 ` Glauber Costa 2012-09-18 14:03 ` Glauber Costa 2012-09-18 14:03 ` [PATCH v3 01/13] memcg: Make it possible to use the stock for more than one page Glauber Costa 2012-09-18 14:03 ` Glauber Costa 2012-09-18 14:03 ` Glauber Costa 2012-10-01 18:48 ` Johannes Weiner 2012-10-01 18:48 ` Johannes Weiner 2012-09-18 14:03 ` [PATCH v3 02/13] memcg: Reclaim when more than one page needed Glauber Costa 2012-09-18 14:03 ` Glauber Costa 2012-09-18 14:03 ` Glauber Costa 2012-10-01 19:00 ` Johannes Weiner 2012-10-01 19:00 ` Johannes Weiner 2012-09-18 14:04 ` [PATCH v3 03/13] memcg: change defines to an enum Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-10-01 19:06 ` Johannes Weiner 2012-10-01 19:06 ` Johannes Weiner 2012-10-01 19:06 ` Johannes Weiner 2012-10-02 9:10 ` Glauber Costa 2012-10-02 9:10 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 04/13] kmem accounting basic infrastructure Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-21 16:34 ` Tejun Heo 2012-09-21 16:34 ` Tejun Heo 2012-09-24 8:09 ` Glauber Costa 2012-09-24 8:09 ` Glauber Costa 2012-09-24 8:09 ` Glauber Costa 2012-09-26 14:03 ` Michal Hocko 2012-09-26 14:03 ` Michal Hocko 2012-09-26 14:03 ` Michal Hocko 2012-09-26 14:33 ` Glauber Costa 2012-09-26 14:33 ` Glauber Costa 2012-09-26 16:01 ` Michal Hocko 2012-09-26 16:01 ` Michal Hocko 2012-09-26 16:01 ` Michal Hocko 2012-09-26 17:34 ` Glauber Costa 2012-09-26 17:34 ` Glauber Costa 2012-09-26 16:36 ` Tejun Heo 2012-09-26 16:36 ` Tejun Heo 2012-09-26 16:36 ` Tejun Heo 2012-09-26 17:36 ` Glauber Costa 2012-09-26 17:36 ` Glauber Costa 2012-09-26 17:44 ` Tejun Heo 2012-09-26 17:44 ` Tejun Heo 2012-09-26 17:44 ` Tejun Heo 2012-09-26 17:53 ` Glauber Costa 2012-09-26 17:53 ` Glauber Costa 2012-09-26 18:01 ` Tejun Heo 2012-09-26 18:01 ` Tejun Heo 2012-09-26 18:56 ` Glauber Costa 2012-09-26 18:56 ` Glauber Costa 2012-09-26 18:56 ` Glauber Costa 2012-09-26 19:34 ` Tejun Heo 2012-09-26 19:34 ` Tejun Heo 2012-09-26 19:34 ` Tejun Heo 2012-09-26 19:46 ` Glauber Costa 2012-09-26 19:46 ` Glauber Costa 2012-09-26 19:56 ` Tejun Heo 2012-09-26 19:56 ` Tejun Heo 2012-09-26 19:56 ` Tejun Heo 2012-09-26 20:02 ` Glauber Costa 2012-09-26 20:02 ` Glauber Costa 2012-09-26 20:16 ` Tejun Heo 2012-09-26 20:16 ` Tejun Heo 2012-09-26 20:16 ` Tejun Heo 2012-09-26 21:24 ` Glauber Costa 2012-09-26 21:24 ` Glauber Costa 2012-09-26 22:10 ` Tejun Heo 2012-09-26 22:10 ` Tejun Heo 2012-09-26 22:10 ` Tejun Heo 2012-09-26 22:29 ` Glauber Costa 2012-09-26 22:29 ` Glauber Costa 2012-09-26 22:42 ` Tejun Heo 2012-09-26 22:42 ` Tejun Heo 2012-09-26 22:42 ` Tejun Heo 2012-09-26 22:54 ` Glauber Costa 2012-09-26 22:54 ` Glauber Costa 2012-09-26 23:08 ` Tejun Heo 2012-09-26 23:08 ` Tejun Heo 2012-09-26 23:08 ` Tejun Heo 2012-09-26 23:20 ` Glauber Costa 2012-09-26 23:20 ` Glauber Costa 2012-09-26 23:33 ` Tejun Heo 2012-09-26 23:33 ` Tejun Heo 2012-09-27 12:15 ` Michal Hocko 2012-09-27 12:15 ` Michal Hocko 2012-09-27 12:15 ` Michal Hocko 2012-09-27 12:20 ` Glauber Costa 2012-09-27 12:20 ` Glauber Costa 2012-09-27 12:40 ` Michal Hocko 2012-09-27 12:40 ` Michal Hocko 2012-09-27 12:40 ` Michal Hocko 2012-09-27 12:40 ` Glauber Costa 2012-09-27 12:40 ` Glauber Costa 2012-09-27 12:40 ` Glauber Costa 2012-09-27 12:54 ` Michal Hocko 2012-09-27 12:54 ` Michal Hocko 2012-09-27 14:28 ` Mel Gorman 2012-09-27 14:28 ` Mel Gorman 2012-09-27 14:28 ` Mel Gorman 2012-09-27 14:49 ` Tejun Heo 2012-09-27 14:49 ` Tejun Heo 2012-09-27 14:57 ` Glauber Costa 2012-09-27 14:57 ` Glauber Costa 2012-09-27 17:46 ` Tejun Heo 2012-09-27 17:46 ` Tejun Heo 2012-09-27 17:46 ` Tejun Heo 2012-09-27 17:56 ` Michal Hocko 2012-09-27 17:56 ` Michal Hocko 2012-09-27 18:45 ` Glauber Costa 2012-09-27 18:45 ` Glauber Costa 2012-09-30 7:57 ` Tejun Heo 2012-09-30 7:57 ` Tejun Heo 2012-09-30 7:57 ` Tejun Heo 2012-09-30 8:02 ` Tejun Heo 2012-09-30 8:02 ` Tejun Heo 2012-09-30 8:56 ` James Bottomley 2012-09-30 8:56 ` James Bottomley 2012-09-30 8:56 ` James Bottomley 2012-09-30 10:37 ` Tejun Heo 2012-09-30 10:37 ` Tejun Heo 2012-09-30 10:37 ` Tejun Heo 2012-09-30 11:25 ` James Bottomley 2012-09-30 11:25 ` James Bottomley 2012-10-01 0:57 ` Tejun Heo 2012-10-01 0:57 ` Tejun Heo 2012-10-01 0:57 ` Tejun Heo 2012-10-01 8:43 ` Glauber Costa 2012-10-01 8:43 ` Glauber Costa 2012-10-01 8:46 ` Glauber Costa 2012-10-01 8:46 ` Glauber Costa 2012-10-03 22:59 ` Tejun Heo 2012-10-03 22:59 ` Tejun Heo 2012-10-01 8:36 ` Glauber Costa 2012-10-01 8:36 ` Glauber Costa 2012-09-27 12:08 ` Michal Hocko 2012-09-27 12:08 ` Michal Hocko 2012-09-27 12:08 ` Michal Hocko 2012-09-27 12:11 ` Glauber Costa 2012-09-27 12:11 ` Glauber Costa 2012-09-27 14:33 ` Tejun Heo 2012-09-27 14:33 ` Tejun Heo 2012-09-27 14:43 ` Mel Gorman 2012-09-27 14:43 ` Mel Gorman 2012-09-27 14:43 ` Mel Gorman 2012-09-27 14:58 ` Tejun Heo 2012-09-27 14:58 ` Tejun Heo 2012-09-27 18:30 ` Glauber Costa 2012-09-27 18:30 ` Glauber Costa 2012-09-30 8:23 ` Tejun Heo 2012-09-30 8:23 ` Tejun Heo 2012-10-01 8:45 ` Glauber Costa 2012-10-01 8:45 ` Glauber Costa 2012-10-03 22:54 ` Tejun Heo 2012-10-03 22:54 ` Tejun Heo 2012-10-04 11:55 ` Glauber Costa 2012-10-04 11:55 ` Glauber Costa 2012-10-06 2:19 ` Tejun Heo 2012-10-06 2:19 ` Tejun Heo 2012-10-06 2:19 ` Tejun Heo 2012-09-27 15:09 ` Michal Hocko 2012-09-27 15:09 ` Michal Hocko 2012-09-30 8:47 ` Tejun Heo [this message] 2012-09-30 8:47 ` Tejun Heo 2012-10-01 9:27 ` Michal Hocko 2012-10-01 9:27 ` Michal Hocko 2012-10-03 22:43 ` Tejun Heo 2012-10-03 22:43 ` Tejun Heo 2012-10-03 22:43 ` Tejun Heo 2012-10-05 13:47 ` Michal Hocko 2012-10-05 13:47 ` Michal Hocko 2012-10-05 13:47 ` Michal Hocko 2012-09-26 22:11 ` Johannes Weiner 2012-09-26 22:11 ` Johannes Weiner 2012-09-26 22:11 ` Johannes Weiner 2012-09-26 22:45 ` Glauber Costa 2012-09-26 22:45 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 05/13] Add a __GFP_KMEMCG flag Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:15 ` Rik van Riel 2012-09-18 14:15 ` Rik van Riel 2012-09-18 15:06 ` Christoph Lameter 2012-09-18 15:06 ` Christoph Lameter 2012-09-18 15:06 ` Christoph Lameter 2012-09-19 7:39 ` Glauber Costa 2012-09-19 7:39 ` Glauber Costa 2012-09-19 7:39 ` Glauber Costa 2012-09-19 14:07 ` Christoph Lameter 2012-09-19 14:07 ` Christoph Lameter 2012-09-19 14:07 ` Christoph Lameter 2012-09-27 13:34 ` Mel Gorman 2012-09-27 13:34 ` Mel Gorman 2012-09-27 13:41 ` Glauber Costa 2012-09-27 13:41 ` Glauber Costa 2012-10-01 19:09 ` Johannes Weiner 2012-10-01 19:09 ` Johannes Weiner 2012-09-18 14:04 ` [PATCH v3 06/13] memcg: kmem controller infrastructure Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-20 16:05 ` JoonSoo Kim 2012-09-20 16:05 ` JoonSoo Kim 2012-09-20 16:05 ` JoonSoo Kim 2012-09-21 8:41 ` Glauber Costa 2012-09-21 8:41 ` Glauber Costa 2012-09-21 8:41 ` Glauber Costa 2012-09-21 9:14 ` JoonSoo Kim 2012-09-21 9:14 ` JoonSoo Kim 2012-09-26 15:51 ` Michal Hocko 2012-09-26 15:51 ` Michal Hocko 2012-09-26 15:51 ` Michal Hocko 2012-09-27 11:31 ` Glauber Costa 2012-09-27 11:31 ` Glauber Costa 2012-09-27 13:44 ` Michal Hocko 2012-09-27 13:44 ` Michal Hocko 2012-09-27 13:44 ` Michal Hocko 2012-09-28 11:34 ` Glauber Costa 2012-09-28 11:34 ` Glauber Costa 2012-09-28 11:34 ` Glauber Costa 2012-09-30 8:25 ` Tejun Heo 2012-09-30 8:25 ` Tejun Heo 2012-10-01 8:28 ` Glauber Costa 2012-10-01 8:28 ` Glauber Costa 2012-10-03 22:11 ` Tejun Heo 2012-10-03 22:11 ` Tejun Heo 2012-10-03 22:11 ` Tejun Heo 2012-10-01 9:44 ` Michal Hocko 2012-10-01 9:44 ` Michal Hocko 2012-10-01 9:44 ` Michal Hocko 2012-10-01 9:48 ` Michal Hocko 2012-10-01 9:48 ` Michal Hocko 2012-10-01 9:48 ` Michal Hocko 2012-10-01 10:09 ` Glauber Costa 2012-10-01 10:09 ` Glauber Costa 2012-10-01 11:51 ` Michal Hocko 2012-10-01 11:51 ` Michal Hocko 2012-10-01 11:51 ` Glauber Costa 2012-10-01 11:51 ` Glauber Costa 2012-10-01 11:51 ` Glauber Costa 2012-10-01 11:58 ` Michal Hocko 2012-10-01 11:58 ` Michal Hocko 2012-10-01 12:04 ` Glauber Costa 2012-10-01 12:04 ` Glauber Costa 2012-10-01 12:04 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 07/13] mm: Allocate kernel pages to the right memcg Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-27 13:50 ` Mel Gorman 2012-09-27 13:50 ` Mel Gorman 2012-09-28 9:43 ` Glauber Costa 2012-09-28 9:43 ` Glauber Costa 2012-09-28 9:43 ` Glauber Costa 2012-09-28 13:28 ` Mel Gorman 2012-09-28 13:28 ` Mel Gorman 2012-09-27 13:52 ` Michal Hocko 2012-09-27 13:52 ` Michal Hocko 2012-09-27 13:52 ` Michal Hocko 2012-09-18 14:04 ` [PATCH v3 08/13] res_counter: return amount of charges after res_counter_uncharge Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-10-01 10:00 ` Michal Hocko 2012-10-01 10:00 ` Michal Hocko 2012-10-01 10:01 ` Glauber Costa 2012-10-01 10:01 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 09/13] memcg: kmem accounting lifecycle management Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-10-01 12:15 ` Michal Hocko 2012-10-01 12:15 ` Michal Hocko 2012-10-01 12:15 ` Michal Hocko 2012-10-01 12:29 ` Glauber Costa 2012-10-01 12:29 ` Glauber Costa 2012-10-01 12:29 ` Glauber Costa 2012-10-01 12:36 ` Michal Hocko 2012-10-01 12:36 ` Michal Hocko 2012-10-01 12:36 ` Michal Hocko 2012-10-01 12:43 ` Glauber Costa 2012-10-01 12:43 ` Glauber Costa 2012-10-01 12:43 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 10/13] memcg: use static branches when code not in use Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-10-01 12:25 ` Michal Hocko 2012-10-01 12:25 ` Michal Hocko 2012-10-01 12:27 ` Glauber Costa 2012-10-01 12:27 ` Glauber Costa 2012-10-01 12:27 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 11/13] memcg: allow a memcg with kmem charges to be destructed Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-10-01 12:30 ` Michal Hocko 2012-10-01 12:30 ` Michal Hocko 2012-10-01 12:30 ` Michal Hocko 2012-09-18 14:04 ` [PATCH v3 12/13] execute the whole memcg freeing in rcu callback Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-21 17:23 ` Tejun Heo 2012-09-21 17:23 ` Tejun Heo 2012-09-21 17:23 ` Tejun Heo 2012-09-24 8:48 ` Glauber Costa 2012-09-24 8:48 ` Glauber Costa 2012-09-24 8:48 ` Glauber Costa 2012-10-01 13:27 ` Michal Hocko 2012-10-01 13:27 ` Michal Hocko 2012-10-01 13:27 ` Michal Hocko 2012-10-04 10:53 ` Glauber Costa 2012-10-04 10:53 ` Glauber Costa 2012-10-04 10:53 ` Glauber Costa 2012-10-04 14:20 ` Glauber Costa 2012-10-04 14:20 ` Glauber Costa 2012-10-05 15:31 ` Johannes Weiner 2012-10-05 15:31 ` Johannes Weiner 2012-10-05 15:31 ` Johannes Weiner 2012-10-08 9:45 ` Glauber Costa 2012-10-08 9:45 ` Glauber Costa 2012-09-18 14:04 ` [PATCH v3 13/13] protect architectures where THREAD_SIZE >= PAGE_SIZE against fork bombs Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-09-18 14:04 ` Glauber Costa 2012-10-01 13:17 ` Michal Hocko 2012-10-01 13:17 ` Michal Hocko 2012-10-01 13:17 ` 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=20120930084750.GI10383@mtj.dyndns.org \ --to=tj@kernel.org \ --cc=cgroups@vger.kernel.org \ --cc=devel@openvz.org \ --cc=fweisbec@gmail.com \ --cc=glommer@parallels.com \ --cc=hannes@cmpxchg.org \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=mhocko@suse.cz \ --cc=rientjes@google.com \ --cc=suleiman@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.