Re: the cost of inlining?
On Fri, Dec 05, 2014 at 01:32:35AM +, Jeff Haran wrote:
> $ cat atomic_read.c
>
> #include
> #include
>
> int samp_atomic_read(atomic_t *v)
> {
> int val;
>
> val = atomic_read(v);
> return val;
> }
I couldn't get it to build with the #inclue , but it built
when I removed it.
> I dump the resultant .ko, I get this:
>
> > objdump -S -M intel atomic_read.ko
>
> atomic_read.ko: file format elf64-x86-64
>
>
> Disassembly of section .text:
>
> :
> #include
> #include
>
> int samp_atomic_read(atomic_t *v)
> {
>0: 55 push rbp
>1: 48 89 e5movrbp,rsp
>4: e8 00 00 00 00 call 9
> *
> * Atomically reads the value of @v.
> */
> static inline int atomic_read(const atomic_t *v)
> {
> return v->counter;
>9: 8b 07 moveax,DWORD PTR [rdi]
> int val;
>
> val = atomic_read(v);
> return val;
> }
>b: c9 leave
>c: c3 ret
>d: 90 nop
>e: 90 nop
>f: 90 nop
>
My ouput differs:
john@vega:~/foo$ objdump -S -M intel atomic_read.ko
atomic_read.ko: file format elf64-x86-64
Disassembly of section .text:
:
0: 55push rbp
1: 8b 07 moveax,DWORD PTR [rdi]
3: 48 89 e5 movrbp,rsp
6: 5dpoprbp
7: c3ret
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem in Getting Mainline Kernel
My cloning process showed no visible errors, but 'git status' print thousands of [Deleted]. I think that is why I miss nearly all the directories in my git directory. Anyway, now I'm using: rsync -av --progress rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . rsync is resumable. Hope it works :) All the best! Freeman Original Message > Am 04.12.14 um 14:58 schrieb Freeman Zhang: >> Hi Kristof, >> >> You are right, I did clone the source on mac os. And I am really >> suffering :( > > I just tried it myself. Cloning works at least without *visible* errors. > Cross compiling on OSX will lead to errors though I guess because of the > aforementioned case insensivity. > > I'm on Yosemity, btw. > >> >> >> All the best! >> >> Freeman >> >> Original Message >>> On 2014-12-04 20:21:58 (+0800), Freeman Zhang >>> wrote: Finally I cloned the mainline kernel from "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". However, when I'm looking at the git directory, I got nothing but: . ..arch .DS_Store .git .gitignore .mailmap >>> Are you by any chance trying to do this on an OS X machine? >>> That's going to lead to pain and suffering. >>> >>> For example, there are a couple of files which have the same name with >>> different case, which isn't going to work on a default OS X install. >>> By default OS X has a case insensitive file system. It's possible to >>> change that, but you *really* want a Linux system to build the kernel. >>> >>> Regards, >>> Kristof >>> >> >> >> >> ___ >> Kernelnewbies mailing list >> Kernelnewbies@kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> signature.asc Description: OpenPGP digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
the cost of inlining?
Hoping this isn't too far off the topic, but I figure it might be of interest
to other kernel developers and it has me a bit baffled.
The primary benefit to inlining functions is to avoid the cost of making
function calls. At least that's how I've understood it.
So I was playing with a bit of sample code:
$ cat atomic_read.c
#include
#include
int samp_atomic_read(atomic_t *v)
{
int val;
val = atomic_read(v);
return val;
}
atomic_read() is declared like so:
static inline int atomic_read(const atomic_t *v)
{
return v->counter;
}
So I figured the compilation of the my sample code would result in no call to a
function with samp_atomic_read().
But after I build the above with the following Makefile:
$ cat Makefile
obj-m += atomic_read.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
I dump the resultant .ko, I get this:
> objdump -S -M intel atomic_read.ko
atomic_read.ko: file format elf64-x86-64
Disassembly of section .text:
:
#include
#include
int samp_atomic_read(atomic_t *v)
{
0: 55 push rbp
1: 48 89 e5movrbp,rsp
4: e8 00 00 00 00 call 9
*
* Atomically reads the value of @v.
*/
static inline int atomic_read(const atomic_t *v)
{
return v->counter;
9: 8b 07 moveax,DWORD PTR [rdi]
int val;
val = atomic_read(v);
return val;
}
b: c9 leave
c: c3 ret
d: 90 nop
e: 90 nop
f: 90 nop
I think I understand most of it. The first 2 instructions save the base pointer
of the caller and setup a new one from samp_atomic_read().
The instruction at offset 9 reads the contents of v->counter into eax to return
to the caller.
The instruction at offset 0xb, restores the base pointer and stack pointer of
the caller and the ret at offset 0xc returns execution to the caller. I am
guessing the nops at the end are to make the next function land on an 8 byte
boundary (this is for an X86_64 target).
But what is that call instruction at offset 4 for?
It would seem to accomplish nothing since without it execution would proceed at
the mov at offset 9 like I'd expect and since no new base frame gets setup
inside atomic_read() itself, the leave/ret causes control to return to the
caller of samp_atomic_read() anyway.
If atomic_read() were a macro, we wouldn't have this seemingly superfluous call
instruction.
Anybody know why it's there?
Thanks,
Jeff Haran
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem in Getting Mainline Kernel
Am 04.12.14 um 14:58 schrieb Freeman Zhang: > Hi Kristof, > > You are right, I did clone the source on mac os. And I am really > suffering :( I just tried it myself. Cloning works at least without *visible* errors. Cross compiling on OSX will lead to errors though I guess because of the aforementioned case insensivity. I'm on Yosemity, btw. > > > All the best! > > Freeman > > Original Message >> On 2014-12-04 20:21:58 (+0800), Freeman Zhang >> wrote: >>> Finally I cloned the mainline kernel from >>> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". >>> However, when I'm looking at the git directory, I got nothing but: >>> >>> . .. arch .DS_Store .git .gitignore .mailmap >>> >> Are you by any chance trying to do this on an OS X machine? >> That's going to lead to pain and suffering. >> >> For example, there are a couple of files which have the same name with >> different case, which isn't going to work on a default OS X install. >> By default OS X has a case insensitive file system. It's possible to >> change that, but you *really* want a Linux system to build the kernel. >> >> Regards, >> Kristof >> > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: stability ?
I agree with Valdis here, unlike user space the kernel has too many weird use cases on different hardware or configs for one developer to test alone. Through Intel does have their test lab for Linux now :). Regards Nick On 2014-12-04 10:02 AM, valdis.kletni...@vt.edu wrote: > On Thu, 04 Dec 2014 11:37:45 +0800, libin said: >> Does anybody know what test should do before a patch added into the >> kernel ? I am interested in the method to prove the stability and performance >> of kernel , especially the stability . > > That will of course be *heavily* dependent on the exact nature of the > patch. The Linux kernel is developed with a "lots of small incremental > patches" philosophy. As a result, most patches are relatively minor > and only require testing that they work - so if it compiles, boots, and > you test whatever function the patch does, that's sufficient. Your webcam > now outputs RGB like it should, not GBR like it was? Excellent. The ethernet > driver no longer crashes when it sees a packet that's exactly 1397 bytes > long? Great. Package it up and submit it. > > If you're adding new functionality, you of course want to test a bit more. > > Boot the kernel, and let it run for a few days, make sure you don't have > any memory leaks or stray pointers or other crashes. That's probably all > the testing most patches actually get. And that's OK, most well-written > patches don't *need* more testing. > > If you're ambitious and writing patches that are more invasive, get xfstests > and/or the Linux Test Project package and run those against your new kernel. > Note that you may need to write new test routines if you added new function. > > If you're *really* hardcore, get 'trinity' and run that against your kernel. > Make sure to back the test system up first, it *can* eat your system. > > The *real* problem is that the Linux kernel ends up getting used in lots > of weird configurations - far too many for any developer to test. And > stability > issues come in two flavors: Ones that kill your own box in an hour of light > use, and ones that only happen on a very small number of systems, none of them > yours. > > I personally manage to trip over 3-4 bugs in linux-next each release cycle, > just because I do stuff on my Dell laptop that developers obviously didn't > have a way to test. For instance, right now I'm trying to track down a > nasty bug in drivers/net/tun.c where it's pretty obvious that the guy who > wrote the commit tested what he could (he has a reputation of doing good > work), but the Juniper VPN software my employer uses gives it indigestion. > Wasn't any way for Herbert to test that one without a Juniper VPN box to > test against... > > Linus had a *long* chase after one bug, that turned out two be two > instructions in the wrong order in an asm() statement, which would lead to > a system hang if an interrupt came in between the two instructions. So > there was a race condition window *literally* 2 cycles wide - and *one* user > had a workload that was able to pretty frequently drop an interrupt into > that billionth of a second window. Frequent as in "managed that impossible > shot several times a day" > > And the only real way to find that sort of weirdness is to get the patch into > linux-next and then have lots of linux-next testers with different use > cases > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: stability ?
On Thu, 04 Dec 2014 11:37:45 +0800, libin said: > Does anybody know what test should do before a patch added into the > kernel ? I am interested in the method to prove the stability and performance > of kernel , especially the stability . That will of course be *heavily* dependent on the exact nature of the patch. The Linux kernel is developed with a "lots of small incremental patches" philosophy. As a result, most patches are relatively minor and only require testing that they work - so if it compiles, boots, and you test whatever function the patch does, that's sufficient. Your webcam now outputs RGB like it should, not GBR like it was? Excellent. The ethernet driver no longer crashes when it sees a packet that's exactly 1397 bytes long? Great. Package it up and submit it. If you're adding new functionality, you of course want to test a bit more. Boot the kernel, and let it run for a few days, make sure you don't have any memory leaks or stray pointers or other crashes. That's probably all the testing most patches actually get. And that's OK, most well-written patches don't *need* more testing. If you're ambitious and writing patches that are more invasive, get xfstests and/or the Linux Test Project package and run those against your new kernel. Note that you may need to write new test routines if you added new function. If you're *really* hardcore, get 'trinity' and run that against your kernel. Make sure to back the test system up first, it *can* eat your system. The *real* problem is that the Linux kernel ends up getting used in lots of weird configurations - far too many for any developer to test. And stability issues come in two flavors: Ones that kill your own box in an hour of light use, and ones that only happen on a very small number of systems, none of them yours. I personally manage to trip over 3-4 bugs in linux-next each release cycle, just because I do stuff on my Dell laptop that developers obviously didn't have a way to test. For instance, right now I'm trying to track down a nasty bug in drivers/net/tun.c where it's pretty obvious that the guy who wrote the commit tested what he could (he has a reputation of doing good work), but the Juniper VPN software my employer uses gives it indigestion. Wasn't any way for Herbert to test that one without a Juniper VPN box to test against... Linus had a *long* chase after one bug, that turned out two be two instructions in the wrong order in an asm() statement, which would lead to a system hang if an interrupt came in between the two instructions. So there was a race condition window *literally* 2 cycles wide - and *one* user had a workload that was able to pretty frequently drop an interrupt into that billionth of a second window. Frequent as in "managed that impossible shot several times a day" And the only real way to find that sort of weirdness is to get the patch into linux-next and then have lots of linux-next testers with different use cases pgpKNgdvZbLiZ.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem in Getting Mainline Kernel
Hi Kristof, You are right, I did clone the source on mac os. And I am really suffering :( All the best! Freeman Original Message > On 2014-12-04 20:21:58 (+0800), Freeman Zhang > wrote: >> Finally I cloned the mainline kernel from >> "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". >> However, when I'm looking at the git directory, I got nothing but: >> >> . .. arch .DS_Store .git .gitignore .mailmap >> > Are you by any chance trying to do this on an OS X machine? > That's going to lead to pain and suffering. > > For example, there are a couple of files which have the same name with > different case, which isn't going to work on a default OS X install. > By default OS X has a case insensitive file system. It's possible to > change that, but you *really* want a Linux system to build the kernel. > > Regards, > Kristof > signature.asc Description: OpenPGP digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem in Getting Mainline Kernel
On 2014-12-04 20:21:58 (+0800), Freeman Zhang wrote: > Finally I cloned the mainline kernel from > "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". > However, when I'm looking at the git directory, I got nothing but: > > . .. arch .DS_Store .git .gitignore .mailmap > Are you by any chance trying to do this on an OS X machine? That's going to lead to pain and suffering. For example, there are a couple of files which have the same name with different case, which isn't going to work on a default OS X install. By default OS X has a case insensitive file system. It's possible to change that, but you *really* want a Linux system to build the kernel. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem in Getting Mainline Kernel
On Thu, Dec 4, 2014 at 10:21 AM, Freeman Zhang wrote: > Hi list, > > I cloned it for nearly 30 hours due to the poor connection :( How I wish > the cloning process is resumable. > > Finally I cloned the mainline kernel from > "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". > However, when I'm looking at the git directory, I got nothing but: > > . .. arch .DS_Store .git .gitignore .mailmap > > I'm confused. I thought it would be like this: > > arch include mm security > block init modules.builtin sound > COPYINGipc modules.orderSystem.map > CREDITSKbuild Module.symvers tools > crypto Kconfig net usr > Documentation kernel README virt > driverslib REPORTING-BUGS vmlinux > firmware MAINTAINERS samples vmlinux.o > fs Makefile scripts > > Is my clone broken? I ran `git pull` and it said the clone is > up-to-date. And the size of .git directory is over 1 GB. What does 'git status' give you? If you have not modified anything try running `git reset --hard HEAD` it will restore all changes made in the repository. Regards > Now I'm using `tar.xz` from kernel.org and it works just fine. But I > still want to know what I should do with my git clone. > > > All the best! > > Freeman Zhang > > > > > > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Simplicity is the ultimate sophistication ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Problem in Getting Mainline Kernel
Hi list, I cloned it for nearly 30 hours due to the poor connection :( How I wish the cloning process is resumable. Finally I cloned the mainline kernel from "git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git". However, when I'm looking at the git directory, I got nothing but: . .. arch .DS_Store .git .gitignore .mailmap I'm confused. I thought it would be like this: arch include mm security block init modules.builtin sound COPYINGipc modules.orderSystem.map CREDITSKbuild Module.symvers tools crypto Kconfig net usr Documentation kernel README virt driverslib REPORTING-BUGS vmlinux firmware MAINTAINERS samples vmlinux.o fs Makefile scripts Is my clone broken? I ran `git pull` and it said the clone is up-to-date. And the size of .git directory is over 1 GB. Now I'm using `tar.xz` from kernel.org and it works just fine. But I still want to know what I should do with my git clone. All the best! Freeman Zhang signature.asc Description: OpenPGP digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: stability ?
On December 4, 2014 2:27:13 AM EST, libin wrote: > I need is what test should do before a new kernel will be released 。 > >Maybe I will modify some kernel codes for some reason , not only the >drivers , but I don't know whether it is Stable or not , > So I think there should have some standrd tests to run , > So I am interestd in how the linux kernel maintainer do as usual ! > I think you fail to understand the complexity of the kernel. There are some overall tests, but in general each subsystem has tests of their own, so your question has no general answer. I follow file systems. The current paradigm is most file systems maintainers are going about the process of ensuring the "xfstests" test suite runs on their file system. Thus more and more, xfstests has become the default stability tester for many/most Linux file systems. I believe the xfs team in particular run that suite for days prior to accepting major code changes. Even more important is that for any bug fix they update xfstests to ensure it finds the bug. That ensures no regressions on that bug in the future. Xfstests has its own mailing list, but I don't recall if is archived anywhere. BOTH Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
