Yes peter you r right..
But my main concern(which i dint convey properly in subject) is whether
virtual memory allocation has a limit or not.
I got it answered.

Thank you ..

On Tue, May 31, 2011 at 8:57 PM, Peter Teoh [off-list ref] wrote:

To answer your subject:   I think the straight answer is "no".   Many
reason, among them:

ARM is still 32-bit, at least at the present moment:

http://www.google.com/search?q=does+arm+have+64bit&num=100

so with hardware 32-bit based, doing MMU at the 64-bit level is still
not possible (without the MMU 64-bit hardware architecture, I don't
think it is possible to do any >4GB memory translation stuff.   Am I
not wrong?

On Tue, May 31, 2011 at 1:54 PM, sandeep kumar
[off-list ref] wrote:

quoted

Hi all,
The following link gives the memory map for the arm architecture.
http://www.arm.linux.org.uk/developer/memory.txt

I have the following doubts..
1) Any chipset(based on arm) manufacturer(qualcom,samsung..) should

follow

quoted

the same memory map.
Is it hardly constrained or can be changed?
Where are this constraints are implemented in the kernel source tree?

2) while i was student, i read in OS concepts that, "Virtual memory

gives an

quoted

illusion to a process,
that it has always a larger continuous address space (even more than RAM)
available to it."
So i thought i could allocate howmuch ever memory i want.
But seeing the above link,i observed there is some limitation in the

address

quoted

space created by the vmalloc().
So i m now thinking that vmalloc has some limit.

Please make me clear these things....


With regards,
Sandeep Kumar Anantapalli,

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

--
Regards,
Peter Teoh

-- 
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110601/e04fafbf/attachment-0001.html