On Thu, Aug 19, 2010 at 12:07:31AM +0800, Wu, Fengguang wrote:> On Thu, Aug 19, 2010 at 12:06:13AM +0800, Wu Fengguang wrote:> > On Wed, Aug 18, 2010 at 04:13:08PM +0200, Johannes Weiner wrote:> > > Hi Matthew,> > > > > > On Tue, Aug 17, 2010 at 03:50:01PM -0400, Matthew Wilcox wrote:> > > > > > > > No comment on this? Was it just that I posted it during the VM summit?> > > > > > I have not forgotten about it. I just have a hard time reproducing> > > those extreme stalls you observed.> > > > > > Running that test on a 2.5GHz machine with 2G of memory gives me> > > stalls of up to half a second. The patchset I am experimenting with> > > gets me down to peaks of 70ms, but it needs further work.> > > > > > Mapped file pages get two rounds on the LRU list, so once the VM> > > starts scanning, it has to go through all of them twice and can only> > > reclaim them on the second encounter.> > > > > > At that point, since we scan without making progress, we start waiting> > > for IO, which is not happening in this case, so we sit there until a> > > timeout expires.> > > > Right, this could lead to some 1s stall. Shaohua and me also noticed> > this when investigating the responsiveness issues. And we are wondering> > if it makes sense to do congestion_wait() only when the bdi is really> > congested? There are no IO underway anyway in this case.> > > > > This stupid-waiting can be improved, and I am working on that. But> > > > Yeah, stupid waiting :)How about this one?

congestion_wait() blindly sleep without checking if device is really congested.In a workload without any write, it can cause direct page reclaim sleep 100msand hasn't any help for page reclaim.There might be other places calling congestion_wait() and need check ifdevice is really congested, but I can't audit all, so this just changes thedirect page reclaim code path. The new congestion_wait_check() will make sureat least one device is congested before going into sleep.