Kernelnewbies Digest, Vol 64, Issue 37
Vishwas Srivastava
vishu.kernel at gmail.com
Wed Mar 23 04:18:02 EDT 2016
On Tue, Mar 22, 2016 at 8:06 PM, <kernelnewbies-request at kernelnewbies.org>
wrote:
> Send Kernelnewbies mailing list submissions to
> kernelnewbies at kernelnewbies.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> or, via email, send a message with subject or body 'help' to
> kernelnewbies-request at kernelnewbies.org
>
> You can reach the person managing the list at
> kernelnewbies-owner at kernelnewbies.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kernelnewbies digest..."
>
>
> Today's Topics:
>
> 1. Re: Is it possible to turn off the gcc optimization when
> compiling kernel? (Hao Lee)
> 2. Re: kernel_thread() causes segfault (Shashank Khasare)
> 3. Re: Is it possible to turn off the gcc optimization when
> compiling kernel? (Nicholas Mc Guire)
> 4. Re: How to get object virtual address from a kernel core dump
> (Arun Sudhilal)
> 5. Re: Is it possible to turn off the gcc optimization when
> compiling kernel? (Hao Lee)
> 6. Re: kernel_thread() causes segfault (Manoj Nayak)
> 7. Re :Querry Regarding Memory Alignment (Manoj Nayak)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Mar 2016 19:24:38 +0800
> From: Hao Lee <haolee.swjtu at gmail.com>
> Subject: Re: Is it possible to turn off the gcc optimization when
> compiling kernel?
> To: kernelnewbies at kernelnewbies.org
> Cc: Nicholas Mc Guire <der.herr at hofr.at>
> Message-ID:
> <CA+PpKPm=
> eHxK5oj39r8nrT6XGA4qo6XKMNRcgcNCNdGQW_SPvw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Mar 21, 2016 at 5:51 PM, Nicholas Mc Guire <der.herr at hofr.at>
> wrote:
> > You can not turn it off in all functions as some need particluar
> > optimization flags to comile at all, but you can pass
> > individual CFLAGS per file via the Makefile
> >
> > CFLAGS_target.o = -O0 or -flags-to-use
> >
> > aswell as remove specific CFLAGS with
> >
> > CFLAGS_REMOVE_target.o = -flags-to-remove
> >
> > but if you want to debug the kernel it is most likely not
> > a good idea to try and disable optimization as the code you then
> > are debugging might not have that much to do with the final code
> > once optimization is on again. So simply generate the .lst file
> > of the target you are trying to debug e.g. for kernel/sched/core.c:
> >
> > make kernel/sched/core.lst
> >
> > and then use that .lst file to understand the output of gdb you
> > are inspecting.
>
> Thanks for your reply!
> Besides,I also find that use "gcc -c -Q -O1 --help=optimizers" can
> print the exact set of optimizations.
>
> regards,
> Hao Lee
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Mar 2016 16:51:44 +0530
> From: Shashank Khasare <sskkernelnewbie at gmail.com>
> Subject: Re: kernel_thread() causes segfault
> To: kernelnewbies at kernelnewbies.org
> Message-ID:
> <
> CAGwMyOAxpQJjR9LRDLCp-ZLgHqKPcaLuJwDWyowBMsHHs5sjug at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I am trying to implement ideas mentioned in the following OSDI paper:
> L. Soares and M. Stumm. FlexSC: flexible system call scheduling with
> exception-less system calls. In Proc. OSDI, 2010.
>
> http://www.cs.cmu.edu/~chensm/Big_Data_reading_group/papers/flexsc-osdi10.pdf
>
> The paper propose a new mechanism for applications to make syscall.
> The brief idea is to have two types of threads 1) User thread 2) Kernel
> Thread.
> These two threads share same address space, file descriptor tables, parent
> pid etc.
> Whenever user thread wants to make syscall, it would post the information
> about syscall number & arguments
> to syscall in common shared page. User thread would then wait till the
> results are posted on shared page.
> The kernel thread reads the syscall arguments from shared page and writes
> the results to shared page.
> User thread consumes the results and continues execution.
> Since the kernel thread and user thread can be scheduled on different cpu
> cores, and user thread is ideally never executing
> kernel code and vice versa, one can expect gain in instruction per cycle
> for application, since the cache pollution is reduced to
> some extent*.*
>
> So to implement this mechanism, it is important for the user and kernel
> thread to share address space, fd tables etc.
> kernel_thread() works fine with older kernels to achieve this task, but is
> no longer an option.
>
> Is there of any mechanism for sharing fd tables as well?
> Please let me know.
>
> Thanks a lot,
> Shashank
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/1bdf0577/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Tue, 22 Mar 2016 11:35:16 +0000
> From: Nicholas Mc Guire <der.herr at hofr.at>
> Subject: Re: Is it possible to turn off the gcc optimization when
> compiling kernel?
> To: Hao Lee <haolee.swjtu at gmail.com>
> Cc: kernelnewbies at kernelnewbies.org
> Message-ID: <20160322113516.GA11898 at osadl.at>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Mar 22, 2016 at 07:24:38PM +0800, Hao Lee wrote:
> > On Mon, Mar 21, 2016 at 5:51 PM, Nicholas Mc Guire <der.herr at hofr.at>
> wrote:
> > > You can not turn it off in all functions as some need particluar
> > > optimization flags to comile at all, but you can pass
> > > individual CFLAGS per file via the Makefile
> > >
> > > CFLAGS_target.o = -O0 or -flags-to-use
> > >
> > > aswell as remove specific CFLAGS with
> > >
> > > CFLAGS_REMOVE_target.o = -flags-to-remove
> > >
> > > but if you want to debug the kernel it is most likely not
> > > a good idea to try and disable optimization as the code you then
> > > are debugging might not have that much to do with the final code
> > > once optimization is on again. So simply generate the .lst file
> > > of the target you are trying to debug e.g. for kernel/sched/core.c:
> > >
> > > make kernel/sched/core.lst
> > >
> > > and then use that .lst file to understand the output of gdb you
> > > are inspecting.
> >
> > Thanks for your reply!
> > Besides,I also find that use "gcc -c -Q -O1 --help=optimizers" can
> > print the exact set of optimizations.
> >
> yes - but for any given code you will find that many of those
> options actually have no effect for the particular code blob.
> The set of flags effectively impacting the generated object
> file is generally much smaller than the ones reported by
> gcc -c -Q -O1 --help=optimizers.
>
> thx!
> hofrat
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 22 Mar 2016 17:09:08 +0530
> From: Arun Sudhilal <getarunks at gmail.com>
> Subject: Re: How to get object virtual address from a kernel core dump
> To: "Mohammad Y. Zachariah" <eng.myz at gmail.com>
> Cc: Kernel Newbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <
> CABOM9ZrcecujZBfyLXSK8SXPFmkZGWRNH6Y-ZnuxQEZJVHJ15Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Zach,
>
> On Fri, Mar 18, 2016 at 3:28 PM, Mohammad Y. Zachariah <eng.myz at gmail.com>
> wrote:
>
> > Hello everyone,
> >
> > I'm taking the way of analysing kernel core dumps as a learning approach
> > using 'crash tool'. One of the interesting crash commands is 'struct'
> which
> > can print kernel struct definition and/or the actual contents of the
> > structure.
> >
> > According to struct help page, I need the virtual address of the struct
> in
> > order to view/print its contents, for example:
> >
> > crash> mm_struct.pgd ffff810022e7d080 -px
> > pgd_t *pgd = 0xffff81000e3ac000
> > -> {
> > pgd = 0x2c0a6067
> > }
> >
> > My question is how to find the mm_struct address "ffff810022e7d080" in
> the
> > above example in the first place??
> >
>
> crash tool has a 'ps' command, which outputs all the task and their task
> struct address.
>
> Thanks,
> Arun
>
> >
> > Thank you for your help in advance.
> > Zach
> >
> > _______________________________________________
> > Kernelnewbies mailing list
> > Kernelnewbies at kernelnewbies.org
> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/676f2c2d/attachment-0001.html
>
> ------------------------------
>
> Message: 5
> Date: Tue, 22 Mar 2016 19:46:23 +0800
> From: Hao Lee <haolee.swjtu at gmail.com>
> Subject: Re: Is it possible to turn off the gcc optimization when
> compiling kernel?
> To: Nicholas Mc Guire <der.herr at hofr.at>
> Cc: kernelnewbies at kernelnewbies.org
> Message-ID:
> <
> CA+PpKPk4fEZqH7J9khjVoiduT3Sz+rBWpqpHBSk+BNVXLwF0eQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Mar 22, 2016 at 7:35 PM, Nicholas Mc Guire <der.herr at hofr.at>
> wrote:
> > yes - but for any given code you will find that many of those
> > options actually have no effect for the particular code blob.
> > The set of flags effectively impacting the generated object
> > file is generally much smaller than the ones reported by
> > gcc -c -Q -O1 --help=optimizers.
> >
> > thx!
> > hofrat
>
> yeah,only several options take effect.
> Because "-O0" will break the link progress,I just want use "-O1" and
> some other options to approximate the effects of "-O0".
>
> regards,
> Hao Lee
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 22 Mar 2016 19:15:48 +0530
> From: Manoj Nayak <manojnayak2005 at gmail.com>
> Subject: Re: kernel_thread() causes segfault
> To: kernelnewbies at kernelnewbies.org
> Message-ID:
> <CAOsfsFLeO5v5X5obrUeokq=WLdQO3O=
> PjmbfYAU4WB334CBddw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Process has files_struct and fs_struct in task_struct.
>
> Two thread's task_struct can point to same files_struct and fs_struct if
> we do the changes through a new system call.
>
> Please check the following URL.
>
> http://lxr.free-electrons.com/source/kernel/fork.c#L993
>
> Regards
> Manoj Nayak
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/687ef0ce/attachment-0001.html
>
> ------------------------------
>
> Message: 7
> Date: Tue, 22 Mar 2016 20:00:05 +0530
> From: Manoj Nayak <manojnayak2005 at gmail.com>
> Subject: Re :Querry Regarding Memory Alignment
> To: kernelnewbies at kernelnewbies.org
> Message-ID:
> <
> CAOsfsFKdyWR6t6k7WKPwHEe_zRz9KwiUZvpJQCOCqRgOmvx39w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> The CPU always reads at its word size (4 bytes on a 32-bit processor), so
> when you do an unaligned address access ? on a processor that supports it ?
> the processor is going to read multiple words. The CPU will read each word
> of memory that your requested address straddles. This causes multiple
> processor read to access the requested data.
>
> Hardware deals with word size alignment. Other alignment like page size
> alignment is a software feature.
>
> On X86: Any virtual address provided to cpu is split into page aligned
> virtual address and an offset.CPU uses page aligned virtual address to
> check TLB to get page aligned physical address.
>
> Now physical address = Page aligned physical address + offset
>
> If page size is bigger then less no of TLB entries are required for the
> processor. Each page needs one TLB entry.
>
> Regards
> Manoj Nayak
>
Thanks Manoj for the reply
So that means aligned / unaligned virtual address -------- >
aligned/unaligned phy address
and there is one to one analogy in this regard.
SW can actually generate addresses which could be unaligned and then
CPU could fault with
memory alignment fault.
For example, if SW cast a "short" pointer to a "int" pointer and
attempts to access the data
it leads to unaligned access.
Perhaps the Instruction decode unit of the CPU will see that it is word
read at address which is not divisible by 4
and would instruct the control unit to trigger the alignment fault.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160322/56d79c72/attachment.html
>
> ------------------------------
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> End of Kernelnewbies Digest, Vol 64, Issue 37
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160323/6d511388/attachment-0001.html
More information about the Kernelnewbies
mailing list