From mboxrd@z Thu Jan  1 00:00:00 1970
From: mindentropy@gmail.com (mindentropy)
Date: Thu, 21 Jul 2011 22:12:59 +0530
Subject: Regarding remap_pfn_page
In-Reply-To: <CAAYFAvoeyOH1GGX1h1zqGoJrphoD2qyqfQ-SHPiSZeP4W3Zzjw@mail.gmail.com>
References: <201107192326.46034.mindentropy@gmail.com>
	<201107202359.17118.mindentropy@gmail.com>
	<CAAYFAvoeyOH1GGX1h1zqGoJrphoD2qyqfQ-SHPiSZeP4W3Zzjw@mail.gmail.com>
Message-ID: <201107212212.59630.mindentropy@gmail.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

>So your question is rather more confined : Whether you can allocate
>physically cotigous memory of 16MB, right? Mapping is not an issue
>here. proper error handling will anyways tell you whether you
>succeeded or not. I think with kmalloc, you may not get memory larger
>than 4MB.

Yes mapping was never an issue. Contiguous physical frames is an issue. 
kmalloc limitation is 128KB. __get_page_frames  with order higher that 10 
would have higher chances of failing. I guess I need to grab as much 
contiguous memory as possible during boot time. My /proc/buddyinfo on a 512MB 
RAM machine paints a depressing picture of contiguous chunks.