[linux-mm-cc] kernel make benchmark on small x86 desktop

Nai Xia nai.xia at gmail.com
Mon Apr 14 03:13:51 EDT 2008


On Mon, Apr 14, 2008 at 3:01 PM, Nitin Gupta <nitingupta910 at gmail.com> wrote:
>
> On Mon, Apr 14, 2008 at 12:08 PM, Nai Xia <nai.xia at gmail.com> wrote:
>  > Hi, Nitin,
>  >
>  >  Unfortunately, this result is negative.
>  >
>  >  I limited the RAM memory to 56M, after that the kernel compling test was done:
>  >
>  >  # time make -j4 bzImage >/dev/null 2>&1
>  >
>  >  the result without compcache:
>  >  real    125m57.405s
>  >  user    19m28.617s
>  >  sys     2m41.942s
>  >
>  >  the result with default loaded compcache:
>  >  real    153m35.538s
>  >  user    19m45.838s
>  >  sys     4m2.727s
>  >
>  >
>  >  I personally think this give us the information when some "stale"
>  >  anonymous pages get "pinned" in memory for a long time, it is bad  for
>  >  overal performance.
>  >  This will never happen in fillmem benchmark, because it travels the
>  >  memory back and forth,
>  >  the possibility of visiting each page is equal.
>  >
>  >  How do you think ?
>
>
>  kernel compile is page-cache intensive workload, and we only compress
>  swap-cache.
>  So, I think in all such benchmarks which are page-cache intensive will
>  have negative results.
>
>  Ideally compcache should be smart itself to "shut itself off" in such cases :)

hmm, Nice hint :)

But I still think that even with non-page-cache-intensive workloads
there is possibility of "stale pinned anonymous pages" case. For
example, program A allocs a lot of memory and begins to sleep for a
long time. During the longterm sleeping, its pages still take some
precious RAM, which hinders other programs from executing more
efficeintly, right ?

If that will happen, what should we do?

>
>  - Nitin
>


More information about the linux-mm-cc mailing list