From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755491Ab0KHWZr (ORCPT ); Mon, 8 Nov 2010 17:25:47 -0500 Received: from smtp-out.google.com ([74.125.121.35]:14811 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754351Ab0KHWZq convert rfc822-to-8bit (ORCPT ); Mon, 8 Nov 2010 17:25:46 -0500 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=from:to:cc:subject:references:date:in-reply-to:message-id: user-agent:mime-version:content-type:content-transfer-encoding; b=Z7EY4EjqSyJ1FBL26SbHfus3biXj5oqUQfEuKQb3q6GkchNPziTJuQX1f8/ZWQXKX CQo+iQfC3fnsW7Wc0GGrA== From: Greg Thelen To: Minchan Kim Cc: Johannes Weiner , Andrew Morton , Dave Young , Andrea Righi , KAMEZAWA Hiroyuki , Daisuke Nishimura , Balbir Singh , Wu Fengguang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [patch 1/4] memcg: use native word to represent dirtyable pages References: <1288973333-7891-1-git-send-email-minchan.kim@gmail.com> <20101106010357.GD23393@cmpxchg.org> <20101107215030.007259800@cmpxchg.org> <20101107220353.115646194@cmpxchg.org> Date: Mon, 08 Nov 2010 14:25:15 -0800 In-Reply-To: (Minchan Kim's message of "Mon, 8 Nov 2010 07:56:43 +0900") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Minchan Kim writes: > On Mon, Nov 8, 2010 at 7:14 AM, Johannes Weiner wrote: >> The memory cgroup dirty info calculation currently uses a signed >> 64-bit type to represent the amount of dirtyable memory in pages. >> >> This can instead be changed to an unsigned word, which will allow the >> formula to function correctly with up to 160G of LRU pages on a 32-bit Is is really 160G of LRU pages? On 32-bit machine we use a 32 bit unsigned page number. With a 4KiB page size, I think that maps 16TiB (1<<(32+12)) bytes. Or is there some other limit? >> system, assuming 4k pages.  That should be plenty even when taking >> racy folding of the per-cpu counters into account. >> >> This fixes a compilation error on 32-bit systems as this code tries to >> do 64-bit division. >> >> Signed-off-by: Johannes Weiner >> Reported-by: Dave Young > Reviewed-by: Minchan Kim Reviewed-by: Greg Thelen