<div dir="ltr">Hi Valdis,<div><br></div><div>Many thanks for the mail and quick answers. Regarding the point 4 I know there won't be any page fault otherwise its going to be a complete mess for the kernel. But since I have the confusion due to wrong understanding and I want to clear my concepts I am putting my inline comments. Pls confirm and correct my understanding by doing inline reply. Sorry in advance if my question/understanding is wrong.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 27, 2014 at 6:35 PM, <span dir="ltr"><<a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank">Valdis.Kletnieks@vt.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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 particular<br>
> process, is it possible that all the segments say DS, SS, CS, Heap and all<br>
> can be in different page frames. I am asking this for a particular 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 in<br>
> RAM requires 45 pages and in RAM 45 pages are not contiguous avilable, so<br>
> can it be reside from page frame no 100-125 and then again in 140-160 ?<br>
<br>
</span>Yes. In fact, it *probably* ends up in frames 97, 215, 112, 438, etc etc - the<br>
kernel doesn't try too hard to keep them contiguous unless something specifically<br>
requests contiguous allocation.<br>
<span class=""><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 fall<br>
> into this scenario ?<br>
<br>
</span>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>
<span class=""><br>
<br>
> 3. Inside kernel page fault should not happen, I was trying to 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>
</span>Copy from user basically checks for the page's availability first, and 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>
<span class=""><br>
> 4. In case of read/write system call, a normal user program wants to 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 contain<br>
> valid bit for particular pages which correspond to these blocks.</span></blockquote><div><br></div><div><font color="#ff9900">I think this scenario will call for page fault and page fault handler should be invoked.</font></div><div><font color="#ff9900">I believe Page fault handler code will be inside the kernel and it will try to fill the page </font></div><div><font color="#ff9900">frame with that particular file data say with the particular block.</font></div><div><font color="#ff9900"><br></font></div><div><font color="#ff9900">Eventually this page fault handler code will do below mentioned Vector i/o to put the </font></div><div><font color="#ff9900">blocks into page frame.Once done Page table will be updated with valid bit entry and </font></div><div><font color="#ff9900">then user process can acess the data.</font></div><div><font color="#ff9900"><br></font></div><div><font color="#ff9900">In this whole scenario, this page fault is a kind of user space page fault and not a kernel space</font></div><div><font color="#ff9900">page fault, but the page fault handler will execute its handler in kernel space.</font></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""> If these<br>
> blocks are not in page-cache, it will be bring ito RAM by vector i/o with<br>
> the help of bio-vec data structures. Will this scenario triggers the page<br>
> fault inside kernel ?<br>
<br>
</span>I'll leave this one for you to figure out. It's not that hard. (Hint - in the<br>
code path you describe, why would any of those steps cause a page fault?)<br></blockquote><div><br></div><div><font color="#ff9900">Normal block driver Scsi or Sata fetch the particular sector/Block from Disk </font></div><div><font color="#ff9900">with the help of disk controller r/w command and put that block into the page </font></div><div><font color="#ff9900">frame (with the help of Bio structure of request queue) from where CPU acess it. </font></div><div><font color="#ff9900">In this scenario there is no page fault happens.</font></div><div><font color="#ff9900"><br></font></div><div><font color="#ff9900">Can Cpu directly acess the data bypassing the page cache/RAM ?</font></div><div><font color="#ff9900"><br></font></div><div><font color="#ff9900"><br></font></div><div><font color="#000000">Best Regards,</font></div><div><font color="#000000">Krishna</font></div></div><br></div></div></div>