Messages in this thread | | | Date | Thu, 17 Mar 2005 16:17:52 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH] Prezeroing V8 |
| |
Christoph Lameter <clameter@sgi.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |