Re: [Qemu-devel] sh : performance problem

[Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp>]

Lionel Landwerlin wrote:
> Shin-ichiro,
> 
> Sorry, but I cannot apply your patch cleanly on the last qemu-svn.
> 
> Instead, I would like to try another approach. The patch you proposed to
> find (or not) a valid TLB entry has a complexity of O(log2(n)) (or
> something like that if I remember) instead here is a patch with a
> complexity of O(1).

Good work.  I evaluated your patch on my environment, measuring
compile time for empty main() with gcc.

  sh4 : 5.8 [seconds]     O(n) utlb search.
  sh4 : 4.6 [seconds]     O(log2(n)) utlb search.
  sh4 : 4.1 [seconds]     O(1) utlb search by Lionel
  arm : 0.8 [seconds]     (-M versatilepb + Debian ARM)

Your patch has a nice score!

Now I've done the work to increase number of utlb entries from 64 to 256,
and found that the score get arround 2.4 seconds.
I'm trying to increase it to 4096.  Your O(1) search will be more important
as the entry number increase.

> +#if !defined(CONFIG_USER_ONLY)
> +    /* vpn to utlb entry caches (too much space for user emulation) */
> +    uint8_t utlbs_1k[4194304]; /* 222 => 4 Mb */
> +    uint8_t utlbs_4k[1048576]; /* 220 => 1 Mb */
> +    uint8_t utlbs_64k[65536]; /* 216 => 64 Kb */
> +    uint8_t utlbs_1m[4096]; /* 212 => 4 Kb */
> +#endif
>  } CPUSH4State;

Isn't it too gorgeous?
How about allocating them on demand?
I guess sh-linux uses only utlbs_4k[], in general.
If so, 4 Mb utlbs_1k[] is waste.


Regards,
Shin-ichiro KAWASAKI