Hi.

On Tuesday 31 January 2006 08:25, Pavel Machek wrote:
> On Po 30-01-06 23:18:28, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Thursday 26 January 2006 04:45, Nigel Cunningham wrote:
> > > Add a helper which counts the number of patches of a type (all
> > > or userspace only) which are in TASK_UNINTERRUPTIBLE state.
> > > These tasks are signalled (just in case they leave that state at
> > > a later point), but we do not consider freezing to have failed
> > > if and when they do not enter the freezer.
> > >
> > > Note that when they eventually leave TASK_UNINTERRUPTIBLE state,
> > > they will enter the refrigerator, but will immediately exit if
> > > we no longer want to freeze at that point.
> >
> > I think we need to do something like this to prevent problems with
> > freezing under load.
>
> That is dangerous... task in UNINTERRUPTIBLE may hold some lock,
> AFAICT.
>
> No, there's some simple bug in refrigerator, and I/we need to fix
> that. Signals work under load, so refrigerator should, too.

I know you understand English, Pavel! Re-read what I wrote previously! The 
problem is a race. You're telling processes that process I/O to freeze at the 
same time as you're telling processes that submit I/O to freeze. If kjournald 
(eg) enters the refrigerator while dd is still running, dd is going to have a 
chance of getting stuck, waiting for some I/O to complete.

This also means your sys_sync is totally useless if anything is submitting 
I/O, since there will still be I/O being submitted after the sync is done. 
This is why (in the numbers I submitted yesterday), the current 
implementation took so much longer than the new one. The sys_sync really only 
introduces a big delay. It needs to be done after the things that generate 
I/O have been stopped.

Regards,

Nigel

-- 
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net                IRC: #suspend2 on Freenode