On 29 June 2011 12:08, Mulyadi Santosa [off-list ref] wrote:

Hi :)

On Wed, Jun 29, 2011 at 13:30, piyush moghe [off-list ref] wrote:

quoted

Thanks Mulyadi and Prabhu for your enlightening description.

You welcome :)

quoted

What a plight!!! memory has become soo cheap nowadays that I don't have

less

quoted

than 1GB system and difficult to find someone in my knowledge having less
than 1 GB memory.

In embedded world, it's still common scenario.... so it depends on
which side we see it :) That's the flexibility Linux kernel tries to
show...it does well on big memory machine...but it can also run in
small amount of memory... of course, with the right user space
applications :) (hint: Linux slitaz, puppy, tiny core...)

quoted

Although does this means that pages in FCOM will never have page fault?

Everything mapped in kernel space ( I stress the word "mapped") is
designed to stay all the time in RAM in Linux kernel context. So based
on that AFAIK, we won't get page fault in kernel space. This is
strictly design choice IMHO.

quoted

and
if this is true is this the reason why we assign NULL to memory

descriptor (

quoted

mm_struct ) for kernel threads?

because kernel threads don't need to have specific address space owned
to them. They can simply "borrow" last scheduled process' address
space. After all, they just operate in kernel space, which is the same
for all processes, be it kernel threads or normal task.

Thanks Mulyadi for your clarifications!
I am not getting the idea of "borrowing" last run process's address space. A
kernel thread refers only the addresses in kernel's address space (low-mem
area) which is mapped already, isnt it? How does the address space of last
run task comes into picture?

--
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

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

-- 
Regards,
Paraneetharan C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110629/c7e9477e/attachment.html