linux-kernel - Re: [PATCH] VM: Implements the swap-out page-clustering technique

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Sep 2008 23:58:35 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	hamid.jahanjou@...il.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] VM: Implements the swap-out page-clustering technique

On Fri, 05 Sep 2008 11:15:07 +0330 "Hamid R. Jahanjou" <hamid.jahanjou@...il.com> wrote:

> Andrew Morton wrote:
> > I tried that once.  The code all worked as-designed but didn't seem to
> > improve performance much across a spread of workloads.
> >
> > Benchmarks are essential, please.  Good ones.
> Do you recommend any specific benchmarks for memory-related projects ?
> Which
> one did you use for your own implementation ?
> 

Pretty much any and all benchmarks, when there's not enough memory
(boot with mem=).  Kernel compiles, database benchmarks, you name it. 
Basically anything which has a measurable execution time is relevant.

Designing and running these things is a lot of work and thought.  And
it's an integral part of the development process, because some things
are going to get slower and others will show large inter-run variations
and then one needs to get in there and find explanations and hopefully
fixes.

For example, start with small and simple microbenchmarks: run two
processes which concurrently allocate 1*mem, then modify it all
linearly, then read it all linearly.  Build up from there.  Do not
dive into complex benchmarks on day 1, because you'll have no hope of
explaining the results which they produce.

Beware that behaviour on SMP can be very different from behaviour on
uniprocessor because of the relatively large duration of a timeslice. 
Both must be tested.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/