On 29 June 2011 12:08, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:
Hi :)
You welcome :)
On Wed, Jun 29, 2011 at 13:30, piyush moghe <pmkernel@xxxxxxxxx> wrote:
> Thanks Mulyadi and Prabhu for your enlightening description.
In embedded world, it's still common scenario.... so it depends on
> What a plight!!! memory has become soo cheap nowadays that I don't have less
> than 1GB system and difficult to find someone in my knowledge having less
> than 1 GB memory.
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...)
Everything mapped in kernel space ( I stress the word "mapped") is
> Although does this means that pages in FCOM will never have page fault?
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.
because kernel threads don't need to have specific address space owned
>and
> if this is true is this the reason why we assign NULL to memory descriptor (
> mm_struct ) for kernel threads?
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?
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@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Regards,
Paraneetharan C
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
