[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