<div dir="ltr">Hi Pranay,<div><br></div><div>Thanks a bunch for nice explanation.</div><div><br></div><div>Best Regards,</div><div>Krishna</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 10:34 PM, Pranay Srivastava <span dir="ltr"><<a href="mailto:pranjas@gmail.com" target="_blank">pranjas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Oct 27, 2014 at 8:08 PM, Er Krishna <<a href="mailto:erkrishna@gmail.com">erkrishna@gmail.com</a>> wrote:<br>
> Hi Valdis,<br>
><br>
> Many thanks for the mail and quick answers. Regarding the point 4 I know<br>
> there won't be any page fault otherwise its going to be a complete mess for<br>
> the kernel. But since I have the confusion due to wrong understanding and I<br>
> want to clear my concepts I am putting my inline comments. Pls confirm and<br>
> correct my understanding by doing inline reply. Sorry in advance if my<br>
> question/understanding is wrong.<br>
><br>
> On Mon, Oct 27, 2014 at 6:35 PM, <<a href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>> wrote:<br>
>><br>
>> On Mon, 27 Oct 2014 18:15:15 +0530, Er Krishna said:<br>
>><br>
>> > 1. In case of Paging and discontiguous memory allocation for a<br>
>> > particular<br>
>> > process, is it possible that all the segments say DS, SS, CS, Heap and<br>
>> > all<br>
>> > can be in different page frames. I am asking this for a particular<br>
>> > segment<br>
>> > (I know all the segments can be in different non contiguous pages<br>
>> > seperately, but what about one segment in different non contiguous page<br>
>> > frames). For example lets say stack segment (or data segment) which is<br>
>> > in<br>
>> > RAM requires 45 pages and in RAM 45 pages are not contiguous avilable,<br>
>> > so<br>
>> > can it be reside from page frame no 100-125 and then again in 140-160 ?<br>
>><br>
>> Yes. In fact, it *probably* ends up in frames 97, 215, 112, 438, etc etc<br>
>> - the<br>
>> kernel doesn't try too hard to keep them contiguous unless something<br>
>> specifically<br>
>> requests contiguous allocation.<br>
>><br>
>> > 2. In case of execution of fast interrupt handler when other interrupts<br>
>> > are disable, if device controller generate interrupt then it will not<br>
>> > reaches to CPU ? Is it loss of interrupts and not a good condition on<br>
>> > system/driver ? Can we ignore it safely for our driver or we must not<br>
>> > fall<br>
>> > into this scenario ?<br>
>><br>
>> In general, losing interrrupts isn't a good idea. Whether it's acceptable<br>
>> for your driver or not will depend on your hardware, and basically depends<br>
>> on the answer to the question "What does your hardware do if it requests<br>
>> an interrupt, and it decides it needs another interrupt before the first<br>
>> one has been serviced?" Some devices are stupid, and totally lose the<br>
>> plot if this happens - others are smarter and can either coalesce the<br>
>> interrupts or just ask again after then first one has been serviced.<br>
>><br>
>><br>
>> > 3. Inside kernel page fault should not happen, I was trying to<br>
>> > understand<br>
>> > it w.r.t copy from/to usr api. Say on usr address the particular page is<br>
>> > not there and kernel wants to copy it in kernel address space? What will<br>
>> > happen if we use memcpy rather than copy from usr, will the kernel crash<br>
>> > due to page fault? how copy from usr prevents this? Is the page fault<br>
>> > handler code always remains in RAM in case of Linux Kernel ?<br>
>><br>
>> Copy from user basically checks for the page's availability first, and<br>
>> requests<br>
>> a page in, and then waits for the page to arrive, to avoid the nasty mess<br>
>> of taking a page fault inside the kernel.<br>
>><br>
>> > 4. In case of read/write system call, a normal user program wants to<br>
>> > acess<br>
>> > some file or more specifically (direct or indirect block of particular<br>
>> > inode). This user space process page table which is in RAM doesn't<br>
>> > contain<br>
>> > valid bit for particular pages which correspond to these blocks.<br>
><br>
><br>
> I think this scenario will call for page fault and page fault handler should<br>
> be invoked.<br>
> I believe Page fault handler code will be inside the kernel and it will try<br>
> to fill the page<br>
> frame with that particular file data say with the particular block.<br>
><br>
> Eventually this page fault handler code will do below mentioned Vector i/o<br>
> to put the<br>
> blocks into page frame.Once done Page table will be updated with valid bit<br>
> entry and<br>
> then user process can acess the data.<br>
<br>
</div></div>Read/Write would be done into your user space buffer. Page cache pages<br>
are not part of your process (well not unless you mapped them and even<br>
then only for Reads when you try to modify it you get a copy which<br>
becomes part of your process address space) If this memory buffer or<br>
page which is specific to your process is not present then it must've<br>
been swapped out. So to bring them back file system isn't involved.<br>
<span class=""><br>
><br>
> In this whole scenario, this page fault is a kind of user space page fault<br>
> and not a kernel space<br>
> page fault, but the page fault handler will execute its handler in kernel<br>
> space.<br>
</span>No it's not a signal to your userspace process. When you access a<br>
memory area the fault is triggered by the processor whenever that<br>
memory area doesn't have a valid page table entry. The kernel handles<br>
this processor fault and finds out if the offending address is present<br>
in any of the vm_area_struct belonging to your process. If it finds<br>
any then it'll install the PTE either from swap or by allocating a new<br>
page (in case of acess after a brk) or if it belongs to a file then by<br>
calling the file system specific code to read in the page from disk.<br>
<br>
If the address isn't found you get SEGFAULT, if you've installed a<br>
handler in user-space to handle that segfault then it would execute<br>
the user space handler otherwise the process dies. So regardless of<br>
having a user space handler or not the kernel's fault handler code<br>
does executes but how the PTE is installed depends on how the fault<br>
was triggered.<br>
<span class=""><br>
><br>
>><br>
>> If these<br>
>> > blocks are not in page-cache, it will be bring ito RAM by vector i/o<br>
>> > with<br>
>> > the help of bio-vec data structures. Will this scenario triggers the<br>
>> > page<br>
>> > fault inside kernel ?<br>
>><br>
>> I'll leave this one for you to figure out. It's not that hard. (Hint - in<br>
>> the<br>
>> code path you describe, why would any of those steps cause a page fault?)<br>
><br>
><br>
> Normal block driver Scsi or Sata fetch the particular sector/Block from Disk<br>
> with the help of disk controller r/w command and put that block into the<br>
> page<br>
> frame (with the help of Bio structure of request queue) from where CPU acess<br>
> it.<br>
> In this scenario there is no page fault happens.<br>
</span>What you described above happens in response to a page fault. The<br>
above is not the cause but the effect of one of the ways in which page<br>
fault got triggered. It may not even happen if the pages were already<br>
in Page cache and they are uptodate.<br>
<span class="">><br>
> Can Cpu directly acess the data bypassing the page cache/RAM ?<br>
</span>What do you mean by this I don't understand. Page cache isn't for CPU,<br>
it's purpose is to improve performance. I don't get your question<br>
really.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> Best Regards,<br>
> Krishna<br>
><br>
><br>
> _______________________________________________<br>
> Kernelnewbies mailing list<br>
> <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
> <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
><br>
<br>
<br>
<br>
--<br>
---P.K.S<br>
</div></div></blockquote></div><br></div>