Re: [PATCH] [5/48] Suspend2 2.1.9.8 for 2.6.12:350-workthreads.patch

[Nigel Cunningham]

Hi.

On Tue, 2005-07-12 at 20:57, Pavel Machek wrote:
> Hi!
> 
> > > Again, why do you think you need this?
> > 
> > 1. If something should be wrong with the freezer, it forms part of a
> > safety net that stops your data on disk being trashed.
> 
> > 2. Separating out threads doing syncing from threads submitting I/O
> > makes the refrigerator much more reliable, even under extreme load.
> 
> This seems to be red herring. Sometimes sync took way too long (like
> hours) with older kernels and reiserfs, but I believe that has been
> fixed. If not, we need to fix it, anyway; no need to work around it in
> suspend2.

Are you considering races such as the case where one process is
submitting I/O (say dd) while another is trying to sync? Even if sync
does return sooner (presumably because it only syncs writes submitted
before the sync), there will still be dirty data after the sync
completes. And if we start another sync thread, it will suffer the same
problem. The only solution is to stop I/O being submitted, then sync.
But having stopped I/O being submitted, we need to still have the
threads the process the I/O (possibly userspace ones) unfrozen. Hence we
need to differentiate 'syncthreads'.

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Be amazed that people believe it happened. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/