Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757911Ab0DGMKG (ORCPT ); Wed, 7 Apr 2010 08:10:06 -0400 Received: from mail-yw0-f172.google.com ([209.85.211.172]:62411 "EHLO mail-yw0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757704Ab0DGMKD convert rfc822-to-8bit (ORCPT ); Wed, 7 Apr 2010 08:10:03 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uy75dikf5keA0xwvZD2DwI+yc4YdpdeVDmGMcfQI7Ysig8YiE+MMg/YpnmshK+euFt 2M4SE/UQIHHBJZQ4n5fnbYidIR4kBP1YLwasghmahWpnAZ0Du2zM/XHhNWSGz5v5iiD4 UMOPddLIUsfCDBv7wmf78TrhCLfuI/dNurxtM= MIME-Version: 1.0 In-Reply-To: References: <4BBB8F07.60401@zytor.com> <3715922601579231267@unknownmsgid> <4BBBC470.4050002@zytor.com> <4BBBE976.1000603@zytor.com> Date: Wed, 7 Apr 2010 07:10:02 -0500 Message-ID: Subject: Re: why choose 896MB to the start point of ZONE_HIGHMEM From: Xianghua Xiao To: Venkatram Tummala Cc: "H. Peter Anvin" , Youngwhan Song , Joel Fernandes , Frank Hu , hayfeng Lee , "linux-kernel@vger.kernel.org" , "linux-kernel@zh-kernel.org" , "kernelnewbies@nl.linux.org" 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 Content-Length: 2149 Lines: 57 On Wed, Apr 7, 2010 at 12:48 AM, Venkatram Tummala wrote: > I completely agree with you. I was just trying to clarify Xianghua's > statement "last 128 MB is used for HIGHMEM". I got the feeling that he > thought that last 128MB can be used for vmalloc, IO and for HIGHMEM. So, i > was clarifying that last 128MB is not "used for highmem" but it is used to > support highmem.(among many other things). That was what i intended. > > On Tue, Apr 6, 2010 at 7:09 PM, H. Peter Anvin wrote: >> >> On 04/06/2010 07:04 PM, Venkatram Tummala wrote: >> > Hey Xiao, >> > >> > last 128MB is not used for highmem. last 128MB is used for data >> > structures(page tables etc.) to support highmem .  Highmem is not >> > something which is "INSIDE" Kernel's Virtual Address space. Highmem >> > refers to a region of "Physical memory" which can be mapped into >> > kernel's virtual address space through page tables. >> > >> > Regards, >> > Venkatram Tummala >> > >> >> Not quite. >> >> The vmalloc region is for *anything which is dynamically mapped*, which >> includes I/O, vmalloc, and HIGHMEM (kmap). >> >>        -hpa >> >> -- >> H. Peter Anvin, Intel Open Source Technology Center >> I work for Intel.  I don't speak on their behalf. >> > > Thanks Venkatram, do these sound right: 1. All HIGHMEM(physical address beyond 896MB) are kmapped back into the last 128MB kernel "virtual" address space(using page tables stored in the last 128MB physical address). That also implies it's a very limited virtual space for large memory system and need do kunmap when you're done with it(so you can kmap other physical memories in). I'm not familiar with large-memory systems, not sure how kmap cope with that using this limited 128M window assuming kernel is 1:3 split. 2. The last 128MB physical address can be used for page tables(kmap), vmalloc, IO,etc Regards, Xianghua -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/