This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: kprobe example watching block device access


Frank Ch. Eigler wrote:
Hi -

wcohen wrote:


I have an example module working tracking the number of generic_make_request() calls and sectors transferred on a per device basis. It takes advantage of the current serial nature of the kprobe execution. [...]

Did you have suggestions on the intrumentation itself regardless of it being written in C?


To me, the remarkable aspects about this example are:

- how much shorter and more robust this should be in systemtap script
  rather than C.  It should be only a handful of lines total:

    #! /usr/bin/stap
    probe kernel::function("generic_make_request") {
        count_generic_make_request ++;
        sectors_transferred += /*bio_sectors(bio)*/;
        bin_bdev[bio] = /*bio->bi_bdev*/;
        bin_bd_dev[bio] = /*bio->bi_bdev->bd_dev*/;
        ++bin_count[bio];
        bin_sectors[bio] += /*bio_sectors(bio)*/;
    }
    global bin_bdev, bin_bd_dev, bin_count, bin_sectors;
    global count_generic_make_request, sectors_transferred;


Yes, much of the crud in the C version would go away: no code for setup/shutdown and associative arrays handle more concisely. The mechanism to get the data out is pretty weak, have to unload the module to get the data.

- how important it is to be able to dereference C data structures
(the struct bio *) from within such a script. I don't have a clear idea yet about how best to express such operations, either
specialized or generalized. (Thus the /* */ stuff above.)
Someone still needs to dwelve into the whole "provider" concept,
which is closely related.

Doing the concrete examples is helping to see what works and doesn't work in the instrumentation. I am going to try to implement some of the other ones suggested by Ingo.


One place I cheated in the kprobebio example was using the knowledge that kprobes are currently sequential. There isn't any locking for the associative array used in the example it is relying on the kprobe lock.

-Will



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]