Wednesday, February 25, 2015

Winner takes it all for Big Companies ( Innovation) . Hype is the main business tactic to sell startups

I like this quotation because this is how present market trend is going on now a days...

Apple is getting huge money as profit even though they release only one model per year. All remaining companies are actually struggling to sustain in better place. Here only Apple  is getting more profit compared to other all companies  producing mobile phones. Apple is the actual winner with innovation.


Ola cab is the good example to get Hype. I am sure he will sell his company to big amount soon. From last few months they are spending lot money to give benefits to cab drivers and cheaper rates to customers. Ideally it is not possible. Ideally their aim is to get more customer base even though initially they make losses. After getting very good customer base , they can sell to big companies for awesome price. This is marker strategy i feel.

Same thing i am seeing with Pay-Tm. How paytm can provide discounts. All are following same strategy . I hope soon Paytm also will be sold to big company and PayTm founder will make money.


Wednesday, February 11, 2015

ACCESS_ONCE() usage in linux kernel

Most concurrent access to data should be protected by locks. Spinlocks and mutexes both function as optimization barriers,meaning that they prevent optimizations on one side of the barrier from carrying over to the other. If code only accessesa shared variable with the relevant lock held, and if that variable can only change when the lock is released (and held by a different thread), the compiler will not create subtle problems.

It is only in places where shared data is accessed without locks (or explicit barriers) that a construct like ACCESS_ONCE() is required.

The actual implementation of ACCESS_ONCE(), found in <linux/compiler.h>, is fairly straightforward:

    #define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))


In this case x variable can be declared as  volatile would deoptimize things much more than is necessary. Rather than do that,  the developers involved used ACCESS_ONCE() and things work as they should. So, making the variable as volatileat run time when ever it is required.


Consider, for example, the following code snippet from kernel/mutex.c:

for (;;) {

         struct task_struct *owner;
          owner = ACCESS_ONCE(lock->owner);
          if (owner && !mutex_spin_on_owner(lock, owner))
                 break;
 /* ... */

Compiler can optimize the code like below  if  lock->owner is not volatile:

    owner = ACCESS_ONCE(lock->owner);
    for (;;) {
            if (owner && !mutex_spin_on_owner(lock, owner))
            break;


What the compiler has missed is the fact that lock->owner is being changed byanother thread of execution entirely. The result is code that will fail to noticeany such changes as it executes the loop multiple times, leading to unpleasantresults. The ACCESS_ONCE()call prevents this optimization happening, with theresult that the code (hopefully) executes as intended.

Tuesday, February 10, 2015

How to decide function call arguments passing for performance improvement

I would be considering ARM v7 architecture to explain this topic.

ARM has R0 to R15 registers.
R0 to R3 will be used for passing function arguments.
R0 and R1 basically used for return values.

So ideally till 4 words , function can pass arguments through registers. If it is more , it will push it to stack.

Func( int , double , int )  =>  if we call function like this

R0 -> int
R1 -> unused ( due to alignment needed , R1 will not be used for Double)
R2, R3 -> combinely holds Double value
stack -> final int will be placed in stack


Modify the function like below: 
Func( int ,  int , double )  =>  if we call function like this

R0 -> int

R1, R2 -> combinely holds Double value
R3 -> int

We avoided using stack by arranging arguments in proper order.

This will avoid usage of stack and will improve performance.

Thursday, February 5, 2015

__asm__ __volatile__ usage in linux kernel source

__asm__ is a gcc extension of permitting assembly language statements to be entered nested within your C code

If our assembly statement must execute where we put it, (i.e. must not be moved out of a loop as an optimization), put the keyword volatile after asm and before the ()’s. So to keep it from moving, deleting and all, we declare it as
asm volatile ( ... : ... : ... : ...);
Use __volatile__ when we have to be verymuch careful.
If our assembly is just for doing some calculations and doesn’t have any side effects, it’s better not to use the keyword volatile. Avoiding it helps gcc in optimizing the code and making it more beautiful.

Building Linux Kernel from Source

1. Download the Latest Stable Kernel

The first step is to download the latest stable kernel from kernel.org.

# cd /usr/src/

# wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.9.3.tar.xz



2. Untar the Kernel Source

The second step is to untar the kernel source file for compilation.

# tar -xvJf linux-3.9.3.tar.xz


3. Configure the Kernel
# cd linux-3.9.3

# make menuconfig



4) Compile the Linux Kernel

Compile the main kernel: # make


Compile the kernel modules:# make modules


Install the kernel modules:# make modules_install


At this point, you should see a directory named /lib/modules/3.9.3/ in your system.

5. Install the new kernel on the system:

# make install

6. Boot Linux to the new Kernel
# reboot