Posts

Yesterday I submitted all patches, one for linux-kernel and one for netdev. Normally git send-email saves me and automatically cc all stakeholders (if you construct you patch correctly) but this time I missed the whole kvm maillingslist and all involved stakeholders - shit happens. ;-) I furthermore asked davem how about to use of a special, but proprietary gcc extension. As I think we can gain some performance gains if we permit this extension - let’s wait and see …

The “Munich Symphony Orchestra”:http://www.muenchenevent.de/veranstaltungen/Der_Herr_der_Ringe-1825.html will perform during Apil 2011 the Lord of the Rings Epos with chorus, soloists and more then 250 assistants - sounds great! PS: http://www.youtube.com/watch?v=R-4nH1ajQJY

Nearly 99 percent of all kernel patches touch someones code. Someone is often the maintainer of the subsystem or another developer who is responsible for special tweaks. So the patch should not limited to some maillinglist but should also be addressed directly to the stakeholders of the code. If you are familiar with the current subsystem you know how is the stakeholder and it easy to Cc the right people. On the other hand if you are working within complete unfamiliar code it is not that easy....

I never realized it because it is courteous in open source projects with more then one programmer to write a meaningful commit message (this is no matter of course in commercial projects). I just noticed that git prints the following message: # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch kvm-accelerator [...] Quite nice … ;)

Occasionally I am forced to build larger parts of kernel, not only the “hot area”. This is mainly caused trough modified header files at a prominent position (e.g. tcp.h) or through some updates where the timestamps are updated. Depending on the current workload I restrict the CPU usage by not provide the full SMP load via -j N. But this is one kind of load - the other is IO/disk load....

(17:17) < fw> pakete kriegt das ding via libnetfilter_queue, was prinzipiell schon richtig ist (17:18) < fw> Typische loesung ist, nur "noch-nicht-klassifiziert" pakete zu queuen, und nach sagen wir 4k aufhoeren (17:18) <hgn> das wird eine baumstruktur (17:19) < fw> so sollte es sein (17:19) <hgn> genau (17:19) < fw> aber fuer l7filter sind alle pakete gleich, und alle pattern auch (17:19) < fw> und das ist schlecht[tm] (17:19) <hgn> ok (17:19) <hgn> das ist wirklich schlecht (17:19) < fw> und es ist c++ ;)

Finally: a dream comes true. Doubling or even increase tenfold the clock frequency of your CPU without costs by modifying some variables. Drawback it just works under use of a hypervisor; a virtual environments under kvm. ;-) Just kidding, but as explained yesterday in a blog posting my idea was to introduce a decoupled behavior of the virtual clock. Actually I had no notion to explain the implementation in detail. Just some aspects: the mechanism does not use a utilize a virtual interrupt, on the contrary a memory page is mapped into the guest....

Today I had the idea of accelerate respective decelerate the time for virtual guest machines. The idea comes into mind with time discrete simulators where the wall clock behavior is not required or rather cumbersome. Linux sophisticated kernel virtualization infrastructure is kvm (Kernel-based Virtual Machine, where Intels VT-x or AMD-V native virtualization technique is used). Several timing systems are supported by QEMU and the kernel side: PIT, an emulation of @Intels i8254@ Programmable Interval Timer, normally with three 16 bit counters, modern back in @i8086@ CPUs days RTC, the real time clock with a interval of 32768 ticks per second to advance the time system reported by interrupt number 8....

(22:37) <fw > hast du nen kvm im kvm, oder fummelst du nur am guest kernel rum? (22:37) <hgn> modular, ich lade die hypervisor abstraktion dynamisch via kvm.ko und kvm-amd.ko (22:38) <hgn> was kann schon passieren, jetzt bleib mal auf den boden! ;) (22:38) <fw > harhar (22:38) <fw > *hgn has quit irc [connection reset by peer] (22:39) <fw > hrhr

The disassembled output of filter.o looks not cache-line friendly, with the current generated code two cache-lines must be hit – at least. A switch statement with two case statements is translated into a sequence of conditional branches like this (arch: @x86_64@): 4b8: 8b 06 mov (%rsi),%eax 4ba: 66 83 f8 35 cmp $0x35,%ax 4be: 0f 84 d8 02 00 00 je 79c <sk_run_filter+0x325> 4c4: 0f 87 07 01 00 00 ja 5d1 <sk_run_filter+0x15a> 4ca: 66 83 f8 15 cmp $0x15,%ax 4ce: 0f 84 cd 02 00 00 je 7a1 <sk_run_filter+0x32a> 4d4: 77 73 ja 549 <sk_run_filter+0xd2> 4d6: 66 83 f8 04 cmp $0x4,%ax 4da: 0f 84 1f 02 00 00 je 6ff <sk_run_filter+0x288> 4e0: 77 29 ja 50b <sk_run_filter+0x94> The whole switch/case jump construct in @run_filter()@ eat exactly 567 byte ....