Alan Stern <[EMAIL PROTECTED]> writes:
> On Mon, 9 Jul 2007, Jeremy Maitin-Shepard wrote:
>> Pavel Machek <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>> > I don't know how to do that mechanism... but if we knew where to trap
>> > filesystem writes, we could simply freeze at that point, and at th
On Mon, 9 Jul 2007, Jeremy Maitin-Shepard wrote:
> Pavel Machek <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > I don't know how to do that mechanism... but if we knew where to trap
> > filesystem writes, we could simply freeze at that point, and at that
> > point only, no?
>
> Any operation at al
Pavel Machek <[EMAIL PROTECTED]> writes:
[snip]
> I don't know how to do that mechanism... but if we knew where to trap
> filesystem writes, we could simply freeze at that point, and at that
> point only, no?
Any operation at all that has an external effect must not occur after
the snapshot is m
Hi!
> > And then you will face the problem of a user task doing I/O during
> > hibernate after the atomic snapshot has been made.
>
> I don't think that this is possible in normal conditions. It would be
> possible
> if, for example, the task were waiting for an unavailable resource and that
>
On Sunday, 8 July 2007 14:09, Pavel Machek wrote:
> Hi!
>
> > > And then you will face the problem of a user task doing I/O during
> > > hibernate after the atomic snapshot has been made.
> >
> > I don't think that this is possible in normal conditions. It would be
> > possible
> > if, for exa
Hi!
> > And then you will face the problem of a user task doing I/O during
> > hibernate after the atomic snapshot has been made.
>
> I don't think that this is possible in normal conditions. It would be
> possible
> if, for example, the task were waiting for an unavailable resource and that
>
On Friday, 6 July 2007 17:01, Alan Stern wrote:
> On Fri, 6 Jul 2007, Rafael J. Wysocki wrote:
>
> > Hi,
> >
> > The main limitation of the freezer is that it cannot handle uninterruptible
> > tasks. Namely, if there are uninterruptible tasks in the system, the
> > freezer
> > returns an error,
On Saturday, 7 July 2007 01:00, Rafael J. Wysocki wrote:
> On Saturday, 7 July 2007 00:38, Oliver Neukum wrote:
> > Am Freitag, 6. Juli 2007 schrieb Oleg Nesterov:
> > > Rafael J. Wysocki wrote:
> > > >
> > > > This patch makes the freezer skip uninterruptible user space tasks (ie.
> > > > such
>
On Saturday, 7 July 2007 13:31, Pavel Machek wrote:
> Hi!
>
> > > I don't think we can do that. I suspect rename looks like:
> > >
> > > write directory entry in source
> > > A)(uninterruptible wait for write)
> > > write directory entry in destination
> > > (uninterruptible wait fo
Hi!
> > I don't think we can do that. I suspect rename looks like:
> >
> > write directory entry in source
> > A) (uninterruptible wait for write)
> > write directory entry in destination
> > (uninterruptible wait for write)
> > write something else
> >
> > If we freeze some tas
Hi!
> The main limitation of the freezer is that it cannot handle uninterruptible
> tasks. Namely, if there are uninterruptible tasks in the system, the freezer
> returns an error, which makes it impossible to suspend the system.
...
> Unfortunately, this mechanism also leads to severe limitation
Hi.
On Saturday 07 July 2007 17:50:18 Pavel Machek wrote:
> Hi!
>
> > The main limitation of the freezer is that it cannot handle
uninterruptible
> > tasks. Namely, if there are uninterruptible tasks in the system, the
freezer
> > returns an error, which makes it impossible to suspend the syst
Hi.
On Saturday 07 July 2007 08:56:21 Rafael J. Wysocki wrote:
> On Friday, 6 July 2007 22:26, Oleg Nesterov wrote:
> > Rafael J. Wysocki wrote:
> > >
> > > This patch makes the freezer skip uninterruptible user space tasks (ie.
such
> > > that have an mm of their own) when counting the tasks to
On Saturday, 7 July 2007 00:38, Oliver Neukum wrote:
> Am Freitag, 6. Juli 2007 schrieb Oleg Nesterov:
> > Rafael J. Wysocki wrote:
> > >
> > > This patch makes the freezer skip uninterruptible user space tasks (ie.
> > > such
> > > that have an mm of their own) when counting the tasks to be froze
On Friday, 6 July 2007 22:26, Oleg Nesterov wrote:
> Rafael J. Wysocki wrote:
> >
> > This patch makes the freezer skip uninterruptible user space tasks (ie. such
> > that have an mm of their own) when counting the tasks to be frozen. As a
> > result, these tasks have the TIF_FREEZE and TIF_SIGPEN
Am Freitag, 6. Juli 2007 schrieb Oleg Nesterov:
> Rafael J. Wysocki wrote:
> >
> > This patch makes the freezer skip uninterruptible user space tasks (ie. such
> > that have an mm of their own) when counting the tasks to be frozen. As a
> > result, these tasks have the TIF_FREEZE and TIF_SIGPENDIN
Rafael J. Wysocki wrote:
>
> This patch makes the freezer skip uninterruptible user space tasks (ie. such
> that have an mm of their own) when counting the tasks to be frozen. As a
> result, these tasks have the TIF_FREEZE and TIF_SIGPENDING flags set, but the
> freezer doesn't wait for them to en
On Fri, 6 Jul 2007, Rafael J. Wysocki wrote:
> Hi,
>
> The main limitation of the freezer is that it cannot handle uninterruptible
> tasks. Namely, if there are uninterruptible tasks in the system, the freezer
> returns an error, which makes it impossible to suspend the system.
>
> This mechani
Hi,
The main limitation of the freezer is that it cannot handle uninterruptible
tasks. Namely, if there are uninterruptible tasks in the system, the freezer
returns an error, which makes it impossible to suspend the system.
This mechanism is used to prevent the situations in which the suspend pr
19 matches
Mail list logo
