Some Kernel Questions/Confusions [Pls help]

Tue Oct 28 10:17:31 EDT 2014

Hi Pranay,

Thanks a bunch for nice explanation.

Best Regards,
Krishna

On Mon, Oct 27, 2014 at 10:34 PM, Pranay Srivastava <pranjas at gmail.com>
wrote:

> On Mon, Oct 27, 2014 at 8:08 PM, Er Krishna <erkrishna at gmail.com> 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, <Valdis.Kletnieks at vt.edu> 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
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
>
>
>
> --
>         ---P.K.S
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20141028/903e4b9f/attachment-0001.html 