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