On Mon, Sep 13, 2010 at 7:07 PM, Mel Gorman [off-list ref] wrote:

On Mon, Sep 13, 2010 at 06:48:10PM +0900, Minchan Kim wrote:

quoted

quoted

quoted

quoted

quoted

quoted

<SNIP>
I'm not saying it is. The objective is to identify a situation where
sleeping until the next write or congestion clears is pointless. We have
already identified that we are not congested so the question is "are we
writing a lot at the moment?". The assumption is that if there is a lot
of writing going on, we might as well sleep until one completes rather
than reclaiming more.

This is the first effort at identifying pointless sleeps. Better ones
might be identified in the future but that shouldn't stop us making a
semi-sensible decision now.

nr_bdi_congested is no problem since we have used it for a long time.
But you added new rule about writeback.

Yes, I'm trying to add a new rule about throttling in the page allocator
and from vmscan. As you can see from the results in the leader, we are
currently sleeping more than we need to.

I can see the about avoiding congestion_wait but can't find about
(writeback < incative / 2) hueristic result.

See the leader and each of the report sections entitled
"FTrace Reclaim Statistics: congestion_wait". It provides a measure of
how sleep times are affected.

"congest waited" are waits due to calling congestion_wait. "conditional waited"
are those related to wait_iff_congested(). As you will see from the reports,
sleep times are reduced overall while callers of wait_iff_congested() still
go to sleep. The reports entitled "FTrace Reclaim Statistics: vmscan" show
how reclaim is behaving and indicators so far are that reclaim is not hurt
by introducing wait_iff_congested().

I saw  the result.
It was a result about effectiveness _both_ nr_bdi_congested and
(writeback < inactive/2).
What I mean is just effectiveness (writeback < inactive/2) _alone_.

I didn't measured it because such a change means that wait_iff_congested()
ignored BDI congestion. If we were reclaiming on a NUMA machine for example,
it could mean that a BDI gets flooded with requests if we only checked the
ratios of one zone if little writeback was happening in that zone at the
time. It did not seem like a good idea to ignore congestion.

You seem to misunderstand my word.
Sorry for not clear sentence.

I don't mean ignore congestion.
First of all, we should consider congestion of bdi.
My meant is whether we need adding up (nr_writeback < nr_inacive /2)
heuristic plus congestion bdi.
It wasn't previous version in your patch but it showed up in this version.
So I thought apparently you have any evidence why we should add such heuristic.

quoted

If we remove (writeback < inactive / 2) check and unconditionally
return, how does the behavior changed?

Based on just the workload Johannes sent, scanning and completion times both
increased without any improvement in the scanning/reclaim ratio (a bad result)
hence why this logic was introduced to back off where there is some
writeback taking place even if the BDI is not congested.

Yes. That's what I want. At least, comment of function should have it
to understand the logic.  In addition, It would be better to add the
number to show how it back off well.

--
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>