From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758053Ab2FZImn (ORCPT ); Tue, 26 Jun 2012 04:42:43 -0400 Received: from mx2.parallels.com ([64.131.90.16]:41141 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756054Ab2FZImj (ORCPT ); Tue, 26 Jun 2012 04:42:39 -0400 Message-ID: <4FE9755B.1040905@parallels.com> Date: Tue, 26 Jun 2012 12:39:55 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Suleiman Souhlal CC: , , Andrew Morton , , Frederic Weisbecker , David Rientjes , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , , , Tejun Heo Subject: Re: [PATCH 02/11] memcg: Reclaim when more than one page needed. References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-3-git-send-email-glommer@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/26/2012 03:33 AM, Suleiman Souhlal wrote: > On Mon, Jun 25, 2012 at 7:15 AM, Glauber Costa wrote: >> From: Suleiman Souhlal >> >> mem_cgroup_do_charge() was written before slab accounting, and expects >> three cases: being called for 1 page, being called for a stock of 32 pages, >> or being called for a hugepage. If we call for 2 or 3 pages (and several >> slabs used in process creation are such, at least with the debug options I >> had), it assumed it's being called for stock and just retried without reclaiming. >> >> Fix that by passing down a minsize argument in addition to the csize. >> >> And what to do about that (csize == PAGE_SIZE && ret) retry? If it's >> needed at all (and presumably is since it's there, perhaps to handle >> races), then it should be extended to more than PAGE_SIZE, yet how far? >> And should there be a retry count limit, of what? For now retry up to >> COSTLY_ORDER (as page_alloc.c does), stay safe with a cond_resched(), >> and make sure not to do it if __GFP_NORETRY. > > The commit description mentions COSTLY_ORDER, but it's not actually > used in the patch. > > -- Suleiman > Yeah, forgot to update the changelog =( But much more importantly, are you still happy with those changes? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH 02/11] memcg: Reclaim when more than one page needed. Date: Tue, 26 Jun 2012 12:39:55 +0400 Message-ID: <4FE9755B.1040905@parallels.com> References: <1340633728-12785-1-git-send-email-glommer@parallels.com> <1340633728-12785-3-git-send-email-glommer@parallels.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Suleiman Souhlal Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, Frederic Weisbecker , David Rientjes , Pekka Enberg , Michal Hocko , Johannes Weiner , Christoph Lameter , devel@openvz.org, kamezawa.hiroyu@jp.fujitsu.com, Tejun Heo On 06/26/2012 03:33 AM, Suleiman Souhlal wrote: > On Mon, Jun 25, 2012 at 7:15 AM, Glauber Costa wrote: >> From: Suleiman Souhlal >> >> mem_cgroup_do_charge() was written before slab accounting, and expects >> three cases: being called for 1 page, being called for a stock of 32 pages, >> or being called for a hugepage. If we call for 2 or 3 pages (and several >> slabs used in process creation are such, at least with the debug options I >> had), it assumed it's being called for stock and just retried without reclaiming. >> >> Fix that by passing down a minsize argument in addition to the csize. >> >> And what to do about that (csize == PAGE_SIZE && ret) retry? If it's >> needed at all (and presumably is since it's there, perhaps to handle >> races), then it should be extended to more than PAGE_SIZE, yet how far? >> And should there be a retry count limit, of what? For now retry up to >> COSTLY_ORDER (as page_alloc.c does), stay safe with a cond_resched(), >> and make sure not to do it if __GFP_NORETRY. > > The commit description mentions COSTLY_ORDER, but it's not actually > used in the patch. > > -- Suleiman > Yeah, forgot to update the changelog =( But much more importantly, are you still happy with those changes? -- 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