Date: Sat, 28 Jan 2006 00:22:51 +0100
From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <nigel@suspend2.net>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, linux-kernel@vger.kernel.org
Subject: Re: [ 00/23] [Suspend2] Freezer Upgrade Patches
Message-ID: <20060127232251.GC1617@elf.ucw.cz>
References: <20060126034518.3178.55397.stgit@localhost.localdomain> <200601271404.08680.nigel@suspend2.net> <200601271318.01985.rjw@sisk.pl> <200601280520.28816.nigel@suspend2.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200601280520.28816.nigel@suspend2.net>
User-Agent: Mutt/1.5.9i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2422
Lines: 59

On So 28-01-06 05:20:28, Nigel Cunningham wrote:
> Hi.
> 
> On Friday 27 January 2006 22:18, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Friday, 27 January 2006 05:04, Nigel Cunningham wrote:
> > > On Friday 27 January 2006 09:10, Rafael J. Wysocki wrote:
> > > > On Thursday, 26 January 2006 04:45, Nigel Cunningham wrote:
> > > > > Hi everyone.
> > > > >
> > > > > This set of patches represents the freezer upgrade patches from
> > > > > Suspend2.
> > > > >
> > > > > The key features of this changeset are:
> > > > >
> > > > > - Use of Christoph Lameter's todo list notifiers, which help with SMP
> > > > >   cleanness.
> > > > > - Splitting the freezing of kernel and userspace processes. Freezing
> > > > >   currently suffers from a race because userspace processes can be
> > > > >   submitting work for kernel threads, thereby stopping them from
> > > > >   responding to freeze messages in a timely manner. The freezer can
> > > > >   thus give up when it doesn't really need to. (This is not normally
> > > > >   a problem only because load is not usually high).
> > > >
> > > > Could you please describe specific situation?
> > >
> > > The simplest example would be:
> > >
> > > dd if=/dev/hda of=/dev/null
> > > echo disk > /sys/power/state
> >
> > Well, I don't think it's a usual kind of workload. :-)
> 
> No, but I/O alone shouldn't have such effect.
> 
> > Anyway, could you please give some details?  I mean how exactly your patch
> > helps in this particular case?
> 
> I thought I did :). Freezing userspace first means the dd thread gets stopped 
> first. Once the dd thread is stopped, the kernel threads processing the I/O 
> requests have a finite amount of work to do (instead of having new work being 
> submitted all the time), and can thus complete that and then be frozen in a 
> far more deterministic fashion.
> 
> Regarding the stats I promised to Pavel, I'm heading home from LCA today, so I 
> probably won't get them prepared until Monday now - unless I get lazy and 
> only do 10 attempts instead of 100 :)

You could swapoff -a to make your cycle a lot faster.... Freezing is
still done in that case, IIRC.
								Pavel
-- 
Thanks, Sharp!
-
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/