On Thu, 17 Mar 2005, Andrew Morton wrote: > > I switched off the page-zeroing hardware for the tests. > > What tests?
For the results on the darn URL. > 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 the workload is touching every byte of the workload immediately after a page fault then prezeroing is not effective. Its only useful for sparse accesses (like page tables etc). > 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? The kernel would have zeroed a page uselessly at an idle time. > > 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? There will be no regression (as shown on the unnamed URL) if the scrubd is only run during idle times (and also there will be no regression if the known zeroed pages are returned to the hotlists and then used). Kscrubd is an experimental configuration option. Switch it off[default] and the zero hotlists are only populated by the return of known zeroed pages via free_hot_zeroed_page etc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
