Some Kernel Questions/Confusions [Pls help]

Mon Oct 27 13:04:39 EDT 2014

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