From mboxrd@z Thu Jan 1 00:00:00 1970 From: mayhs11saini@gmail.com (Shyam Saini) Date: Tue, 7 Jun 2016 04:53:26 +0530 Subject: cross compilation In-Reply-To: <9811.1465249563@turing-police.cc.vt.edu> References: <9811.1465249563@turing-police.cc.vt.edu> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org > Note that due to things like cache line misses, looking at the code will > tell you almost nothing about which is *really* the "best" code... I thought of counting number of instructions in disassembled code for each case. Since I'm only replacing certain API's , rest of the code remains same. For example Replacing ACCESS_ONCE() API with READ_ONCE() Please correct me , if I'm wrong. > Why do you need to cross-compile? Just build the drivers as x86_64. Pretty > much anybody who actually *cares* about performance has moved off 32-bit > kernels a while ago (unless you're stuck with an embedded 32-bit CPU). Earlier, whenever I run this command $ make drivers/staging/rdma/ I was getting this error CONFIG_X86_X32 enabled but no binutils support So, I thought to cross compile for x82. But now it seems i have solved by following this On Tue, Jun 7, 2016 at 3:16 AM, wrote: > On Tue, 07 Jun 2016 02:27:03 +0530, Shyam Saini said: > > > To choose best optimized code, i need to first compile them and then > > disassemble the compiled code, where a change in single line would make > a > > significant difference in the performance. > > Note that due to things like cache line misses, looking at the code will > tell you almost nothing about which is *really* the "best" code... > > > So, my question is how to compile* x86 based network drivers on x86_64 > > Ubuntu machine*. Currently I'm running Ubuntu 14.04. > > Why do you need to cross-compile? Just build the drivers as x86_64. > Pretty > much anybody who actually *cares* about performance has moved off 32-bit > kernels a while ago (unless you're stuck with an embedded 32-bit CPU). > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160607/c204f37e/attachment-0001.html