Re: [PATCH] mm: Implement swap prefetching tweaks

[Peter Williams <pwil3058@bigpond.net.au>]

Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
>
> > +	/*
> > +	 * get_page_state is super expensive so we only perform it every
> > +	 * SWAP_CLUSTER_MAX prefetched_pages.
>
>
> nr_running() is similarly expensive btw.
>
>
> > 	 * We also test if we're the only
> > +	 * task running anywhere. We want to have as little impact on all
> > +	 * resources (cpu, disk, bus etc). As this iterates over every cpu
> > +	 * we measure this infrequently.
> > +	 */
> > +	if (!(sp_stat.prefetched_pages % SWAP_CLUSTER_MAX)) {
> > +		unsigned long cpuload = nr_running();
> > +
> > +		if (cpuload > 1)
> > +			goto out;
>
>
> Sorry, this is just wrong.  If swap prefetch is useful then it's also
> useful if some task happens to be sitting over in the corner calculating
> pi.

On SMP systems, something based on the run queues' raw_weighted_load 
fields (comes with smpnice patch) might be more useful than nr_running() 
as it contains information about the priority of the running tasks. 
Perhaps (raw_weighted_load() > SCHED_LOAD_SCALE) or some variation, 
where raw_weighted_load() is the sum of that field for all CPUs) would 
suffice.  It would mean "there's more than the equivalent of one nice==0 
task running" and shouldn't be any more expensive than nr_running(). 
Dividing SCHED_LOAD_SCALE by some number would be an obvious variation 
to try as would taking into account this process's contribution to the 
weighted load.

Also if this was useful there's no real reason that raw_weighted_load 
couldn't be made available on non SMP systems as well as SMP ones.

Peter
--
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
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/