From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752512AbdI0J6o (ORCPT ); Wed, 27 Sep 2017 05:58:44 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:51786 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751921AbdI0J6k (ORCPT ); Wed, 27 Sep 2017 05:58:40 -0400 Date: Wed, 27 Sep 2017 10:57:56 +0100 From: Roman Gushchin To: Michal Hocko CC: David Rientjes , Johannes Weiner , Tejun Heo , , , Vladimir Davydov , Tetsuo Handa , Andrew Morton , , , Subject: Re: [v8 0/4] cgroup-aware OOM killer Message-ID: <20170927095756.GA4159@castle> References: <20170915105826.hq5afcu2ij7hevb4@dhcp22.suse.cz> <20170915152301.GA29379@castle> <20170918061405.pcrf5vauvul4c2nr@dhcp22.suse.cz> <20170920215341.GA5382@castle> <20170925122400.4e7jh5zmuzvbggpe@dhcp22.suse.cz> <20170925170004.GA22704@cmpxchg.org> <20170926084602.sloinq7gdoyxo23y@dhcp22.suse.cz> <20170927073744.5g7dq5c5spmtgz5g@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170927073744.5g7dq5c5spmtgz5g@dhcp22.suse.cz> User-Agent: Mutt/1.9.0 (2017-09-02) X-Originating-IP: [2620:10d:c092:180::1:52d1] X-ClientProxiedBy: DB6PR07CA0154.eurprd07.prod.outlook.com (2603:10a6:6:16::47) To DM3PR15MB1081.namprd15.prod.outlook.com (2603:10b6:0:12::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a970f34e-3454-4fa7-2b93-08d5058e4761 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075);SRVR:DM3PR15MB1081; X-Microsoft-Exchange-Diagnostics: 1;DM3PR15MB1081;3:307bRlb6AtYoegfW4OfoS8WTt4Ahnm4+1H4k+ld6HjQYnj+/AJMkzQT9C+rYTniwpBF3OX9BWW6BvXbvMaoIH1k2dakwuK+RsLaxbjbj1jVTv4ZOmspPaRhlszSuTlQt54DJd0pgdI0Lm16OYX1E/zuI1icJYFdBCwhDyHMAsp+PwF/Q8d88mxdr/WDMazoW9I91LAEhgvmG+dzb4w4oBI3Ym9imVNrLvexQuWu1EMGjFFVhZsa1wbKMb35wcmtQ;25:041t6WqW5RvsjUNOubUt3iYKby2s0Y1EeKZjOU11cubdH1EGe5F7vwR7yCvV9NrqyFoCGak8vTQgxIy7HDrBwiQY01z96hGfBnKbPzijG55d2I4kR7lUXYlNlZJ/xpv+eYzNwDtMOwd3brSmWr4X5bS+Z+YwAFJA+Z9TgPqcJGDA8Zshwie+gyEigLZIXJZYHrJodLyrzbW5T/7vuW6LVjg2AgxAfdqNRp3glfXrddwKxGOX7R9YV9O139N/CBl8Lc4IpAMxB3/Q0vDcMjQ0MLWa21szi095AO4E8ors1bMAZkFANR1OERSo2oUo9l9auVK21ZvRKvd9+Uc6l85Y6g==;31:iZWtp54ijCYnEIzfOhQyb0i1tfZX9c255htIwMXmUhql98JGuqHlwBJ4mdf/vJSW9FqGn7D3AcmovxoFZa+KAWkQZ7GtKRYJ72vDPz7WwIdS3gXaxk42+zK9Y/AuZqbCbakugDQ4qzeMv8VccyHk2jk875ObZ0eCtNt5iaPn9P892+J+rzK2i74NQbQifff/QU3HoLumQttd4zDsepI77/DqNwZ1QnOt54rU64iq7kU= X-MS-TrafficTypeDiagnostic: DM3PR15MB1081: X-Microsoft-Exchange-Diagnostics: 1;DM3PR15MB1081;20:XznGvH7oVOHzwihUngFjMfCprktItMDJZ0A6I5d6BY+ITu4pJOrBbLFeuQE0BqxV4lBgBmIEdGhjHMEq4xTNAr5RoPy31y2qB6yxhXo73Zj6s3R+GsFgEyEz4d5/vr6AcreSMHB7V7U7muJ3nW3zvA45udqQPUm3McB8ADeEvvFisXJU8jRxZTgM+ech/IChpn94oOrPvChUuYwA1XGUN2nWAGEt2Sd1VJhPpQcrgKp5qlT5ILk3Pl2OCKkW5f1xwBwSmVywz6KJkV+kugU7v3+AGuNSYFG1W90wli+nLZcIhOKe9zT06I6Ge46ewB6d2uqFGxeXA0/vd4hOMUjZ7H4yGzuRZ8l6SKkF/Jjye4dxKVp8rOCmQJRZ607z2M6CJI2f8zVm2kBPs5SJ+gZS0fs305YDCDBdaqHtoIy5anQ3vXUw/NJFGB+e39tqAGII9ZMXVYWgv4fC9Goo1spZkm5Mzb1W0JjAa6RLMrIF8UJe7NhIjp8KCi179SUjEBh1;4:w4n++Ybxy9/Vzl1pBF2+ViKI2FOqyiCG4W8tC1moe3EnaqX7aa5T31NKUu4AIEG3TXnZ27RIi+s5mWOrdXyg38za1VFGs/NN4+WAuE1etwfsm9RbtA0SK1AAEtYvE4mTMkK3HbcVYanF6AscowElE65AaD/NVHwNtwxsJAK96yQIhxqyySu8HtFsMmOnR1BjdpW3GW5a7v7yJEhAy4p0QS8MZBuamEFqdBU33ec4m0kBW7ExFInyLAP9J38pTlvW X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DM3PR15MB1081;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DM3PR15MB1081; X-Forefront-PRVS: 04433051BF X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(376002)(346002)(199003)(189002)(377424004)(24454002)(5890100001)(86362001)(55016002)(53936002)(16586007)(316002)(83506001)(229853002)(97736004)(7736002)(81166006)(8936002)(47776003)(50466002)(8676002)(54906003)(305945005)(58126008)(81156014)(6666003)(6246003)(6116002)(23726003)(50986999)(478600001)(5660300001)(76176999)(4326008)(7416002)(54356999)(6916009)(39060400002)(189998001)(9686003)(2950100002)(33716001)(101416001)(33656002)(68736007)(93886005)(1076002)(106356001)(6496005)(25786009)(2906002)(105586002)(18370500001)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:DM3PR15MB1081;H:castle;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;DM3PR15MB1081;23:I/GbJ54Kpi/NtUb6zXgvig43uM6zjKt5jsZbevalX?= =?us-ascii?Q?ztEF3Rxnzi/MIom4TxXpTBNEgP7ZalgMI9qs9TXjZbsAkq8IZ/xgG1imaMwj?= =?us-ascii?Q?N5drrMVuS01AtmU2ULublaIrxuIIthjdZvRr6lwtnjFDTlViNzaPnW7odPHj?= =?us-ascii?Q?MqrV0AvVvg9EZ6F1c/wjqP8AjHAFmWGEEcqzYbV+38/7Piy/ju+EzL9F4D0P?= =?us-ascii?Q?5qfN/6kEs9zs21TAPcp1w6LobPe16cS8nuVh7avns8D7/e/8qj6fJ41k9wfh?= =?us-ascii?Q?I7sUJTlkiaSWmiQggWUpKohwBYAdDRUzLl39teQl2M9g9hafMjydyURq/y4F?= =?us-ascii?Q?QzNwLNJDpW6nGmIprZqV6DJJFxkThH5AxFWkQZvaOvkU2tbOvvvl2/bC4oDy?= =?us-ascii?Q?rrYgW2YPdprEIBtUp0r9H8KDRr6NeL4jSmTkG7zDwh04z0nsIlG834ZC+hm5?= =?us-ascii?Q?9ml1kgR8FUuPaLKPGPUQwW4QlO2nYLZz4MZ84gykVSk11XZmGvzi0LqfqmTf?= =?us-ascii?Q?FzwNXrlQ16IxPaczseRsgbHvuKoZ0TT3bgI6wegI/ACzzDW+HRIwqSESLuii?= =?us-ascii?Q?Ah81LR46Z9EWUvpQ6/fdvnv4BQVWTciKPRhCpii3OoiF098dMKZmACHboSPY?= =?us-ascii?Q?iazZ6Cvl8zRIn5G2MTlI8tEmK8WR8wVAD8UAqJ2kqNuOd6l8tXt44TloMU03?= =?us-ascii?Q?DE1ObaZxlkK2s+fQLRW5Bg0pE+WPYsOwl47Oa37Ml8npS0PIrgtvLE5xZgzv?= =?us-ascii?Q?9iewsBi7moIjD8dwZqJFh5f+5mGaOdXvL4G+plDO0CHMBQu4eMfDTmphHJ8e?= =?us-ascii?Q?CdhH6tc6z6HTAlB4yourrDmbbJVy3lBwiDAyogoPDbnDqefsanZBegBOEWbU?= =?us-ascii?Q?0eg4/mlMzlOUVuRUxf9WDrbXg9wnFL1KN/aymCyn15bWYusHGqKaq87NvhSu?= =?us-ascii?Q?16jpAQJxVNTf/cm9SwVwQ9+rOJ+Ox+Rps4TP6G0u0cUy4H+cNyoZuxqikToc?= =?us-ascii?Q?6oDncPCNb80/w0Trcpaq/uiAebYp3+IjHERCb5Z6dFzy+DuE8OMefUmo161D?= =?us-ascii?Q?TqTivTFJGvwqn259qPHIh99hsDBoudaMrCj9uGOQ1mpzyOC63OiEkyT3qyCP?= =?us-ascii?Q?qZDgSEqeglnILwvc/91WxNrYMjGDnjuXWLjAxtfdL3bpZ8MxON78THMphnxe?= =?us-ascii?Q?YbPHm2X+Cc8Ie8o3t0+jAqc5lC22PinSJJ85v90AWJRhPViEHg3kUi5HypWE?= =?us-ascii?Q?IaF5vIiMLTY6mC3QQ02pt0NFRwLWb94LiBJLkANljzhfOnOQRgQCNkUCDUkS?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1;DM3PR15MB1081;6:UMB2AeeWEizZktAleAJBlvX/eZJdxqK+UO0EAD5RnNq1022U415N7Iwv9Yr+Ldx/uByoD4PojzlzT8omCKCfmHcmAc++bzNQP8QSO74TV0z7DZYeScpEo2NB1OiwneFK1KPeMtq8/q+WxC8oFoZobYtXEeHa+HIa3xZLF/oOrWthv5w+pMGuiTNyX7ckPplrRkrLtGn6pd9/e3w75aAlCE10AH3dShrq7n3aU5K9AaQuspHR7f9wzLLPlZ2PB452prkbpzcHGxXOzVBH1piLxPhF1aH2Z6/Fc+3eqWF1l9LPhwyqK+D6W3tJH4iIkq4z2qhwV+7AT/DLUg/Il7D5fQ==;5:LOTWU1egGk8lsVnXGXv+utSf3cgvruHu9C0wdKZ6ZnxJ1RMpNIO2TweSVnSgcqOo1JJ0k6cxbOhcRezNFme0ueNsNIk8Xzq96AcvH2u/IkVlPQXrZXSWEWpHveArNJkVrIWBwSQka2+mwu7uPnXk+w==;24:pA7Lbud5q/sLGQ/1x0uh25qmm1TAuMIGUwiGk7/Ozqbbqr60TfDTj/gxLPp/giKJl3uj8HOQXD5LVrCiU03sQORcU39onACpohp9wq3Fjg0=;7:8LI2gh2rRdxSrC4hqtwcjcBwidDjpCsrjLJDEbJAnFP6ddNRYfld0s9/DfpCM84d3IvJiFxUE2fTBwqgZj9WURTooj5aaiLNi4bt6rjfY21bF1O7tcVRhcNZcboT8yE1NyeGoXEzVQKm0CP/SUrTNRiLG6WQ74I2wMhf3Daf4XhK3iEuZQE4a94/zzMRK4BXnheXfjDC5Qum38wBfASwr4rE3ZtqHe4s3goRGfSQ1Ic= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;DM3PR15MB1081;20:Ujn7pLY/ox5tSozslSJz7OQbD/HSJxCiVIk9D87cp8lBY/8h/yRyptPFcvJ8IGJrcYTxaLg9CpMOccQ3eiVbZreswyyo+A4E/tBvaftk+WZZ6AqO4F4q+PwPRC4MHRZ5hcueW6s2FJmjW+HJLBADZ+InMa3oQSQNGfOiCT6/Zto= X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2017 09:58:15.8522 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PR15MB1081 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-27_02:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 27, 2017 at 09:37:44AM +0200, Michal Hocko wrote: > On Tue 26-09-17 14:04:41, David Rientjes wrote: > > On Tue, 26 Sep 2017, Michal Hocko wrote: > > > > > > No, I agree that we shouldn't compare sibling memory cgroups based on > > > > different criteria depending on whether group_oom is set or not. > > > > > > > > I think it would be better to compare siblings based on the same criteria > > > > independent of group_oom if the user has mounted the hierarchy with the > > > > new mode (I think we all agree that the mount option is needed). It's > > > > very easy to describe to the user and the selection is simple to > > > > understand. > > > > > > I disagree. Just take the most simplistic example when cgroups reflect > > > some other higher level organization - e.g. school with teachers, > > > students and admins as the top level cgroups to control the proper cpu > > > share load. Now you want to have a fair OOM selection between different > > > entities. Do you consider selecting students all the time as an expected > > > behavior just because their are the largest group? This just doesn't > > > make any sense to me. > > > > > > > Are you referring to this? > > > > root > > / \ > > students admins > > / \ / \ > > A B C D > > > > If the cumulative usage of all students exceeds the cumulative usage of > > all admins, yes, the choice is to kill from the /students tree. > > Which is wrong IMHO because the number of stutends is likely much more > larger than admins (or teachers) yet it might be the admins one to run > away. This example simply shows how comparing siblinks highly depends > on the way you organize the hierarchy rather than the actual memory > consumer runaways which is the primary goal of the OOM killer to handle. > > > This has been Roman's design from the very beginning. > > I suspect this was the case because deeper hierarchies for > organizational purposes haven't been considered. > > > If the preference is to kill > > the single largest process, which may be attached to either subtree, you > > would not have opted-in to the new heuristic. > > I believe you are making a wrong assumption here. The container cleanup > is sound reason to opt in and deeper hierarchies are simply required in > the cgroup v2 world where you do not have separate hierarchies. > > > > > Then, once a cgroup has been chosen as the victim cgroup, > > > > kill the process with the highest badness, allowing the user to influence > > > > that with /proc/pid/oom_score_adj just as today, if group_oom is disabled; > > > > otherwise, kill all eligible processes if enabled. > > > > > > And now, what should be the semantic of group_oom on an intermediate > > > (non-leaf) memcg? Why should we compare it to other killable entities? > > > Roman was mentioning a setup where a _single_ workload consists of a > > > deeper hierarchy which has to be shut down at once. It absolutely makes > > > sense to consider the cumulative memory of that hierarchy when we are > > > going to kill it all. > > > > > > > If group_oom is enabled on an intermediate memcg, I think the intuitive > > way to handle it would be that all descendants are also implicitly or > > explicitly group_oom. > > This is an interesting point. I would tend to agree here. If somebody > requires all-in clean up up the hierarchy it feels strange that a > subtree would disagree (e.g. during memcg oom on the subtree). I can > hardly see a usecase that would really need a different group_oom policy > depending on where in the hierarchy the oom happened to be honest. > Roman? Yes, I'd say that it's strange to apply settings from outside the OOMing cgroup to the subtree, but actually it's not. The oom_group setting should basically mean that the OOM killer will not kill a random task in the subtree. And it doesn't matter if it was global or memcg-wide OOM. Applied to v9. Thanks! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Gushchin Subject: Re: [v8 0/4] cgroup-aware OOM killer Date: Wed, 27 Sep 2017 10:57:56 +0100 Message-ID: <20170927095756.GA4159@castle> References: <20170915105826.hq5afcu2ij7hevb4@dhcp22.suse.cz> <20170915152301.GA29379@castle> <20170918061405.pcrf5vauvul4c2nr@dhcp22.suse.cz> <20170920215341.GA5382@castle> <20170925122400.4e7jh5zmuzvbggpe@dhcp22.suse.cz> <20170925170004.GA22704@cmpxchg.org> <20170926084602.sloinq7gdoyxo23y@dhcp22.suse.cz> <20170927073744.5g7dq5c5spmtgz5g@dhcp22.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=facebook; bh=/llvobH4WOJuV9hcnopWhkRYJI1ropq84HZw4IbLLWw=; b=AggWVH0PsUxVJ5gPH/6ustI3svwKYwvszahhdyMlXWR29z0K7oqimd0tdG9B6ySKwM5I /dICriHSOOCrqnu8t5p13c7QyhmCAUT5h9S3dam7R3dx/G/ZgLu5OPc8u72xblNJxUzf UcUx+y79/mo8YEtbFZdIotGPW9fzjkf9FuE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/llvobH4WOJuV9hcnopWhkRYJI1ropq84HZw4IbLLWw=; b=IgaDmWhNkaD7Z41Hj4mB3dmniWtja73nB7TNygf5AavLMElA/8M+jcLRlV4UbCHn62bWQ717D5HcyVgeEwWPythhMxK2C4aSUBQncrTdTv5QMHacnDHsQJKX+Gpd/WYZMZAe3WctDCqIfdNG6qYxhazxu8wFq9nV+DXMMxO7tSY= Content-Disposition: inline In-Reply-To: <20170927073744.5g7dq5c5spmtgz5g@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: David Rientjes , Johannes Weiner , Tejun Heo , kernel-team@fb.com, linux-mm@kvack.org, Vladimir Davydov , Tetsuo Handa , Andrew Morton , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org On Wed, Sep 27, 2017 at 09:37:44AM +0200, Michal Hocko wrote: > On Tue 26-09-17 14:04:41, David Rientjes wrote: > > On Tue, 26 Sep 2017, Michal Hocko wrote: > > > > > > No, I agree that we shouldn't compare sibling memory cgroups based on > > > > different criteria depending on whether group_oom is set or not. > > > > > > > > I think it would be better to compare siblings based on the same criteria > > > > independent of group_oom if the user has mounted the hierarchy with the > > > > new mode (I think we all agree that the mount option is needed). It's > > > > very easy to describe to the user and the selection is simple to > > > > understand. > > > > > > I disagree. Just take the most simplistic example when cgroups reflect > > > some other higher level organization - e.g. school with teachers, > > > students and admins as the top level cgroups to control the proper cpu > > > share load. Now you want to have a fair OOM selection between different > > > entities. Do you consider selecting students all the time as an expected > > > behavior just because their are the largest group? This just doesn't > > > make any sense to me. > > > > > > > Are you referring to this? > > > > root > > / \ > > students admins > > / \ / \ > > A B C D > > > > If the cumulative usage of all students exceeds the cumulative usage of > > all admins, yes, the choice is to kill from the /students tree. > > Which is wrong IMHO because the number of stutends is likely much more > larger than admins (or teachers) yet it might be the admins one to run > away. This example simply shows how comparing siblinks highly depends > on the way you organize the hierarchy rather than the actual memory > consumer runaways which is the primary goal of the OOM killer to handle. > > > This has been Roman's design from the very beginning. > > I suspect this was the case because deeper hierarchies for > organizational purposes haven't been considered. > > > If the preference is to kill > > the single largest process, which may be attached to either subtree, you > > would not have opted-in to the new heuristic. > > I believe you are making a wrong assumption here. The container cleanup > is sound reason to opt in and deeper hierarchies are simply required in > the cgroup v2 world where you do not have separate hierarchies. > > > > > Then, once a cgroup has been chosen as the victim cgroup, > > > > kill the process with the highest badness, allowing the user to influence > > > > that with /proc/pid/oom_score_adj just as today, if group_oom is disabled; > > > > otherwise, kill all eligible processes if enabled. > > > > > > And now, what should be the semantic of group_oom on an intermediate > > > (non-leaf) memcg? Why should we compare it to other killable entities? > > > Roman was mentioning a setup where a _single_ workload consists of a > > > deeper hierarchy which has to be shut down at once. It absolutely makes > > > sense to consider the cumulative memory of that hierarchy when we are > > > going to kill it all. > > > > > > > If group_oom is enabled on an intermediate memcg, I think the intuitive > > way to handle it would be that all descendants are also implicitly or > > explicitly group_oom. > > This is an interesting point. I would tend to agree here. If somebody > requires all-in clean up up the hierarchy it feels strange that a > subtree would disagree (e.g. during memcg oom on the subtree). I can > hardly see a usecase that would really need a different group_oom policy > depending on where in the hierarchy the oom happened to be honest. > Roman? Yes, I'd say that it's strange to apply settings from outside the OOMing cgroup to the subtree, but actually it's not. The oom_group setting should basically mean that the OOM killer will not kill a random task in the subtree. And it doesn't matter if it was global or memcg-wide OOM. Applied to v9. Thanks! -- 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: email@kvack.org