It is a pity that QEMU does not outline the TLB lookup code. I do not know how much impact the inlined TLB code has due to icache misses...
Another benefit one gets from outlined TLB code is that it is much easier to gather the amount of time spent in the TLB. one can just profile QEMU and count up how many ticks happened in the outlined TLB translation code. In fact, i do not think outlining QEMU inlined TLB lookup is too hard to implement. one can still keep most of the original inlined TLB code and use call/ret to get a TLB translation. of course, one needs to come up with a new linkage. Xin On Wed, Jun 20, 2012 at 3:57 AM, 陳韋任 (Wei-Ren Chen) <che...@iis.sinica.edu.tw> wrote: > CC'ed to the mailing list. > > -- > Wei-Ren Chen (陳韋任) > Computer Systems Lab, Institute of Information Science, > Academia Sinica, Taiwan (R.O.C.) > Tel:886-2-2788-3799 #1667 > Homepage: http://people.cs.nctu.edu.tw/~chenwj > > > ---------- Forwarded message ---------- > From: Orit Wasserman <owass...@redhat.com> > To: "\"陳韋任 (Wei-Ren Chen)\"" <che...@iis.sinica.edu.tw> > Cc: > Date: Tue, 19 Jun 2012 12:01:08 +0300 > Subject: Re: [Qemu-devel] How to measure guest memory access > (qemu_ld/qemu_st) time? > On 06/19/2012 11:49 AM, 陳韋任 (Wei-Ren Chen) wrote: >> Mind me CC this to ML? :) > sure I will read the threads to understand more. > > Orit >> >>> Well it was a while back (2008-9) ,the company was acquired by IBM a year >>> later : >>> http://www.linux-kvm.org/wiki/images/9/98/KvmForum2008%24kdf2008_2.pdf >>> I think stefan Hanjoczi worked there ... >>> The company used the technology for cross platform guest support but claim >>> to get speedup too >>> (for ppc) don't think the speedup was related to mmu but more to the >>> instruction stream. >>> I hope this is helpful. >> >> Thanks. >> >>> Do you have performance result for the cost of the address translation ? >>> If I understand you are concentrating on ARM ? >> >> The whole discussion thread is on [1], and you can get some feel about >> the cost of address translation here [2]. Yes, ARM is our target right now, >> but I think we are not limit to it. >> >> Regards, >> chenwj >> >> [1] http://www.mail-archive.com/qemu-devel@nongnu.org/msg116159.html >> [2] http://www.mail-archive.com/qemu-devel@nongnu.org/msg116404.html >> >
