Re: [PATCH] Prezeroing V8

[Andrew Morton]

Christoph Lameter <clameter@xxxxxxx> wrote:
>
> On Thu, 17 Mar 2005, Andrew Morton wrote:
> 
> > >  http://oss.sgi.com/projects/page_fault_performance/
> >
> > Oh no, not that page again ;)
> 
> Yes indeed!
> 
> > Seems to say that prezeroing makes negligible difference to kernel builds,
> > but speeds up a big malloc+memset by 3x to 4x, yes?
> 
> Correct.
> 
> > Are there any real-worldish workloads which show an appreciable benefit?
> 
> Ummm. Big loads are our real-worldish workloads here.

Sure, but not malloc+memset+exit.

How much improvement do these big numerical tasks get from the patch?

> > The large speedup for a big memset seems odd - I assume it's simply
> > transferring CPU load from the user's process over to kscrubd.  Or is it
> > the fancy page-zeroing hardware?  How do we differentiate the two?
> 
> I switched off the page-zeroing hardware for the tests.

What tests?

See, a speedup in a simple malloc+memset could be due to either a simple
transfer of load from user to kscrubd, or it could be due to leveraging the
page-zeroing hardware.

The latter, I expect, if the workload is actually touching every byte of
all the pages.  Is it?

If we're doing kscrubd zeroing via memset() then the total system load
would actually be increased if the application is touching every byte, yes?

> > Are there any workloads which are seeing a benefit on a CPU which doesn't
> > have the zeroing hardware?
> 
> Without zeroing hardware the eroing actions are moved to idle
> system time (load < /proc/sys/vm/scrub_load). Its shifting the cpu load.

Right.  We'd expect that to be a net regression if the application is
touching all of the memory and a net win if it is touching the memory
sparsely, yes?


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/