Oscon bof slides

Here is the link to the OSCON php performance bof slides.

Posted at 12:04PM Jul 20, 2009 by Basant Kukreja in technical  |  Comments[0]

vi style key binding for bash.

Bash supports both emap and vi style key binding. emacs is a default keybinding. Users need to use "set -o vi" to switch to vi style binding. I have the carpel tunnel type of problem so I always use vi style binding. In bash, I want to have multi-key binding e.g "th" bind to history command, t1 to last command's 1st argument etc. Frankly speaking, I didn't like the bash vi binding syntax. It is very cryptic and possibly very error prone. Here are my bindings :

te : Print this help
tl : listing files in current directory(run ls command)
th : show history of last 8 commands
t0-t9 : last command arguments 0-9
tt : Last command's all argument
tk : Don't run(kill) the current command but save it in history.
tr : reverse-search-history but conituation must be done by C-r
tc : Equivalent to ctrl-c. kill line and go to input mode
tw : next word
tq : history with shortcut macro
ts : print history to execute command
ty : Change editor : For internal use only
tx : Execute perl expression on current statement
z  : vi-search-again
g : goto mark

How it works :
$ <Esc>te
The above will print the help.
$ ls .bash_keybinding.sh
$ vi <Esc>t1
will expand to
$ vi .bash_keybinding.sh

$ vi <Esc>tq
will show last 25 commands
25 ----> gvim(qp0) dtraceno-op.txt(qp1)
24 ----> cd(qo0) ../books/(qo1)
23 ----> ls(qn0)
22 ----> cd(qm0) solaris(qm1)
20 ----> ls(qk0) -l(qk1)
19 ----> kpdf(qj0) solarispkg.pdf(qj1)
18 ----> kpdf(qi0) solarispkg.pdf(qi1)
16 ----> cd(qg0) ..(qg1)
14 ----> kpdf(qe0) dtrace.pdf(qe1)
12 ----> cd(qc0) ../blogs/(qc1)
9 ----> ls(q90) *.html(q91)
7 ----> cvs(q70) add(q71) dtraceno-op.html(q72)
6 ----> cvs(q60) commit(q61)
5 ----> cd(q50) ~/bin/(q51)
2 ----> gvim(q20) .bash_keybinding.sh(q21)
1 ----> ls(q10) .bash_keybinding.sh(q11)
$ vi <Esc>qi1
will expand to
$ vi solarispkg.pdf

Basically "tq" command generates 25 line history and bound their arguments with "qxx" keys.

Syntax of bash key binding command is horrible. Suppose I want to bind "tc" to Ctrl-C, here is the bind command, I need to use.
bind -m vi-command '"\x74\x63"':"\"\C-a\C-K\""

For a complicated set of operations, I wrote a perl script bashhelper.pl. Here
is how "tq" is bound:
bind -m vi-command -x '"tq":"history 25 | perl $bashhelper --leader q --format-history"'

Here are files for complete reference :
.bash_keybinding.sh
bashhelper.pl

Posted at 06:31PM Jul 30, 2008 by Basant Kukreja in technical  |  Comments[0]

How dtrace have no impact on performance when probes are not in use.

dtrace probes can be used in any "C" applications. Slowly lots of server softwares on solaris are integrating dtrace probes in to their core functionality. Initial fear to a new user is that it may have a impact on performance. Dtrace replaces probes with "nop" instructions when not in use. When users typically uses these probes then it have some impact on performance. I wrote a simple test application to see what happens during runtime of a process. (testapp.c)

#include <stdio.h>
#include <unistd.h>
#include <sys/sdt.h>

void func()
{
    DTRACE_PROBE(firsttestapp, query__func);
}
int main()
{
    int i = 0;
    for(i = 0; i < 100; ++i)
    {
        func();
        sleep(2);
        printf("returned from func call\n");
        fflush(stdout);
    }
}
And a small provider (mytestapp.d):
provider firsttestapp {
probe query__func();
};

In this test application func will be called every 2 seconds. func has a dtrace
probe which doesn't do anything. I compiled my dtrace program using following
steps :
$ cc -c -xarch=generic -g testapp.c
$ dtrace -G -32 -s mytestapp.d testapp.o
$ cc -xarch=generic -g mytestapp.o testapp.o -o testapp

$ dbx ./testapp
(dbx) dis func
0x00011410: func       :        save     %sp, -96, %sp
0x00011414: func+0x0004:        nop
0x00011418: func+0x0008:        nop
0x0001141c: func+0x000c:        ret

Notice that function "func" doesn't have any instruction. It has two nop
instructions. Let us run the application and run a dtrace program from other
terminal which uses this probe and see what happens to the application during
runtime.
bash-3.00# dtrace -l | grep testapp
61026 firsttestapp26498           testapp                              func query-func
# dtrace -n 'firsttestapp*::func:query-func { @[probefunc] = count(); }'
dtrace: description 'firsttestapp*::func:query-func ' matched 1 probe

(dbx) dis func
0x00011410: func       :        save     %sp, -96, %sp
0x00011414: func+0x0004:        nop
0x00011418: func+0x0008:        ta       %icc,0x00000038
0x0001141c: func+0x000c:        ret
0x00011420: func+0x0010:        restore

Notice that 1 of the nop is now replaced with trap instruction "ta %icc,". So
when probes are used "nop" instruction is replaced with a trap instruction.
When probes are not in use, it is simply a nop instruction. This is the reason
that probes have no runtime impact on performance of applications when they are
not in use.




                    
        

            Posted at 
               05:51PM Jul 30, 2008
            by Basant Kukreja in technical  | 
                                        Comments[2]