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

[Nai Xia]

On Mon, Apr 14, 2008 at 3:52 PM, Nitin Gupta <nitingupta910 at gmail.com> wrote:
>
> On Mon, Apr 14, 2008 at 12:43 PM, Nai Xia <nai.xia at gmail.com> wrote:
>  >
>  > 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?
>  >
>
>  Two cases here:
>  1) physical swap device is present
>  2) no phy swap.
>
>  In case (1), compcache should send all pages to physical device.

So this can be achieved by making bio requests to the block layer
without invading the kernel itself?
I'd like to have a try in the following days after I go through the
related kernel parts.

>  For case (2), we can do nothing. In this case, if we run out of
>  memory, then our memory requirements are too much for even compression
>  to handle. So, its not compcache fault :)

   agree,  actually it was case (1) in my mind  :) .

>
>  - Nitin
>