Re: [kvm-ppc-devel] [PATCH] [1/3] kvmppc: add detailed instruction emulation statistics

[Hollis B. <ho...@us...>]

On Monday 14 April 2008 07:23:56 ehr...@li... wrote:
> From: Christian Ehrhardt <ehr...@li...>
>
> This extends the kvm_stat reports for kvm on embedded powerpc. Since kvmppc
> is using emulation (no hardware support yet) this gives people interested
> in performance a detailed split of the emul_instruction counter already
> available. This statistic does not cover e.g. operants of the commands, but
> that way it should have only a small perf impact (never break what you want
> to measure). This feature is configurable in .config under the kvmppc
> virtualization itself.

This array-based approach seems to add a lot of lines of code, and it's also 
copy/paste stuff that is just begging for a typo (e.g. miscounting STHX in 
the STHUX bucket) or being forgotten entirely when adding new emulation code.

A more general approach would be to record just the opcode/extended opcode in 
a variable-sized structure, allocating a new bucket as we encounter a 
previously unseen instruction. I'm thinking of something like this:

log_instruction(inst) {
	bucket = hash_u32(inst, 5);
	list_for_each(l, vcpu->instlog[bucket]) {
		struct instlog = list_entry(l);
		if (instlog->inst == inst) {
			instlog->count++;
			break;
		}
	}
}

emulate(inst) {
	log = get_op(inst);
	switch (get_op(inst)) {
		...
	case 31:
		log |= get_xop(inst);
		switch (inst) {
			...
		}
	}
	log_instruction(log);
}

It looks like we could build a hash table pretty easily with hash_long() and 
list_entry stuff (see fs/mbcache.c for example). So far you've found 17 
different instructions types emulated in the "boot" workload, so 32 entries 
would probably be a reasonable hash size. The same approach could be used for 
SPR accesses, where you've hit 31 different registers. Really I think those 
numbers won't vary much by workload, but rather by guest kernel...

-- 
Hollis Blanchard
IBM Linux Technology Center