On Wed, Oct 04, 2017 at 01:03:54AM +, Bart Van Assche wrote:
> On Wed, 2017-10-04 at 02:47 +0200, Luis R. Rodriguez wrote:
> > 3) Lookup for kthreads which seem to generate IO -- address / review if
> > removal of the freezer API can be done somehow with a quescing. This
> > is
On Wed, Oct 04, 2017 at 01:03:54AM +, Bart Van Assche wrote:
> On Wed, 2017-10-04 at 02:47 +0200, Luis R. Rodriguez wrote:
> > 3) Lookup for kthreads which seem to generate IO -- address / review if
> > removal of the freezer API can be done somehow with a quescing. This
> > is
On Fri, Oct 06, 2017 at 02:07:13PM +0200, Pavel Machek wrote:
>
> Yeah, I was not careful enough reading cover letter. Having series
> where 1-4/5 are ready to go, and 5/5 not-good-idea for years to come
> is quite confusing.
4/5 is not ready to go either, at the very least
On Fri, Oct 06, 2017 at 02:07:13PM +0200, Pavel Machek wrote:
>
> Yeah, I was not careful enough reading cover letter. Having series
> where 1-4/5 are ready to go, and 5/5 not-good-idea for years to come
> is quite confusing.
4/5 is not ready to go either, at the very least
On Tue 2017-10-03 22:49:40, Luis R. Rodriguez wrote:
> On Tue, Oct 03, 2017 at 10:12:04PM +0200, Pavel Machek wrote:
> > On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> > > Now that all filesystems which used to rely on kthread
> > > freezing have been converted to filesystem freeze/thawing
On Tue 2017-10-03 22:49:40, Luis R. Rodriguez wrote:
> On Tue, Oct 03, 2017 at 10:12:04PM +0200, Pavel Machek wrote:
> > On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> > > Now that all filesystems which used to rely on kthread
> > > freezing have been converted to filesystem freeze/thawing
On Wed, Oct 04, 2017 at 02:47:56AM +0200, Luis R. Rodriguez wrote:
> On Tue, Oct 03, 2017 at 11:15:07PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> > > On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > > > Now
On Wed, Oct 04, 2017 at 02:47:56AM +0200, Luis R. Rodriguez wrote:
> On Tue, Oct 03, 2017 at 11:15:07PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> > > On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > > > Now
On 10/03/2017 08:53 PM, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
>
> Signed-off-by: Luis R. Rodriguez
> ---
>
On 10/03/2017 08:53 PM, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
>
> Signed-off-by: Luis R. Rodriguez
> ---
>
On Wed, 2017-10-04 at 02:47 +0200, Luis R. Rodriguez wrote:
> 3) Lookup for kthreads which seem to generate IO -- address / review if
> removal of the freezer API can be done somehow with a quescing. This
> is currently for example being done on SCSI / md.
> 4) Only after all the
On Wed, 2017-10-04 at 02:47 +0200, Luis R. Rodriguez wrote:
> 3) Lookup for kthreads which seem to generate IO -- address / review if
> removal of the freezer API can be done somehow with a quescing. This
> is currently for example being done on SCSI / md.
> 4) Only after all the
On Tue, Oct 03, 2017 at 11:15:07PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> > On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > > Now that all filesystems which used to rely on kthread
> > > freezing have been
On Tue, Oct 03, 2017 at 11:15:07PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> > On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > > Now that all filesystems which used to rely on kthread
> > > freezing have been
On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > Now that all filesystems which used to rely on kthread
> > freezing have been converted to filesystem freeze/thawing
> > we can remove the kernel kthread
On Tuesday, October 3, 2017 8:59:00 PM CEST Rafael J. Wysocki wrote:
> On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> > Now that all filesystems which used to rely on kthread
> > freezing have been converted to filesystem freeze/thawing
> > we can remove the kernel kthread
On Tue, Oct 03, 2017 at 03:09:53PM -0600, Shuah Khan wrote:
> On Tue, Oct 3, 2017 at 3:00 PM, Jiri Kosina wrote:
> > On Tue, 3 Oct 2017, Pavel Machek wrote:
> >
> >> > Again, I agree that the (rare) kthreads that are actually "creating" new
> >> > I/O have to be somehow frozen
On Tue, Oct 03, 2017 at 03:09:53PM -0600, Shuah Khan wrote:
> On Tue, Oct 3, 2017 at 3:00 PM, Jiri Kosina wrote:
> > On Tue, 3 Oct 2017, Pavel Machek wrote:
> >
> >> > Again, I agree that the (rare) kthreads that are actually "creating" new
> >> > I/O have to be somehow frozen and require special
On Tue, Oct 3, 2017 at 3:00 PM, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
>> > Again, I agree that the (rare) kthreads that are actually "creating" new
>> > I/O have to be somehow frozen and require special care.
>>
>> Agreed. Was any effort made to identify
On Tue, Oct 3, 2017 at 3:00 PM, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
>> > Again, I agree that the (rare) kthreads that are actually "creating" new
>> > I/O have to be somehow frozen and require special care.
>>
>> Agreed. Was any effort made to identify those special
On Wed, Oct 04, 2017 at 08:04:49AM +1100, Dave Chinner wrote:
> On Tue, Oct 03, 2017 at 11:53:13AM -0700, Luis R. Rodriguez wrote:
> > Now that all filesystems which used to rely on kthread
> > freezing have been converted to filesystem freeze/thawing
> > we can remove the kernel kthread freezer.
On Wed, Oct 04, 2017 at 08:04:49AM +1100, Dave Chinner wrote:
> On Tue, Oct 03, 2017 at 11:53:13AM -0700, Luis R. Rodriguez wrote:
> > Now that all filesystems which used to rely on kthread
> > freezing have been converted to filesystem freeze/thawing
> > we can remove the kernel kthread freezer.
On Tue, Oct 03, 2017 at 11:53:13AM -0700, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Really? There's no other subsystem that relies on kernel thread
and
On Tue, Oct 03, 2017 at 11:53:13AM -0700, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Really? There's no other subsystem that relies on kernel thread
and
On Tue, 3 Oct 2017, Pavel Machek wrote:
> > Again, I agree that the (rare) kthreads that are actually "creating" new
> > I/O have to be somehow frozen and require special care.
>
> Agreed. Was any effort made to identify those special kernel threads?
I don't think there is any other way than
On Tue, 3 Oct 2017, Pavel Machek wrote:
> > Again, I agree that the (rare) kthreads that are actually "creating" new
> > I/O have to be somehow frozen and require special care.
>
> Agreed. Was any effort made to identify those special kernel threads?
I don't think there is any other way than
On Tue 2017-10-03 22:38:33, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
> > > This point I don't understand. What exactly do you mean?
> >
> > Hibernation:
> >
> > We freeze, do system snapshot, unfreeze, and write image to
> > disk.
>
> Where/why do you unfreeze between
On Tue 2017-10-03 22:38:33, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
> > > This point I don't understand. What exactly do you mean?
> >
> > Hibernation:
> >
> > We freeze, do system snapshot, unfreeze, and write image to
> > disk.
>
> Where/why do you unfreeze between
On Tue, 3 Oct 2017, Jiri Kosina wrote:
> > What about the many drivers outside filesystems that use the
> > set_freezable() / try_to_freeze() / wait_event_freezable() API?
>
> Many/most of them are just completely bogus and pointless.
More specifically -- they don't really care at all whether
On Tue, 3 Oct 2017, Jiri Kosina wrote:
> > What about the many drivers outside filesystems that use the
> > set_freezable() / try_to_freeze() / wait_event_freezable() API?
>
> Many/most of them are just completely bogus and pointless.
More specifically -- they don't really care at all whether
On Tue, Oct 03, 2017 at 10:12:04PM +0200, Pavel Machek wrote:
> On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> > Now that all filesystems which used to rely on kthread
> > freezing have been converted to filesystem freeze/thawing
> > we can remove the kernel kthread freezer.
>
> Are you
On Tue, Oct 03, 2017 at 10:12:04PM +0200, Pavel Machek wrote:
> On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> > Now that all filesystems which used to rely on kthread
> > freezing have been converted to filesystem freeze/thawing
> > we can remove the kernel kthread freezer.
>
> Are you
On Tue, Oct 3, 2017 at 10:38 PM, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
>> > This point I don't understand. What exactly do you mean?
>>
>> Hibernation:
>>
>> We freeze, do system snapshot, unfreeze, and write image to
>> disk.
>
> Where/why do you
On Tue, Oct 3, 2017 at 10:38 PM, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
>> > This point I don't understand. What exactly do you mean?
>>
>> Hibernation:
>>
>> We freeze, do system snapshot, unfreeze, and write image to
>> disk.
>
> Where/why do you unfreeze between
On Tue, 3 Oct 2017, Pavel Machek wrote:
> > This point I don't understand. What exactly do you mean?
>
> Hibernation:
>
> We freeze, do system snapshot, unfreeze, and write image to
> disk.
Where/why do you unfreeze between creating the snapshot and writing it
out?
Again, I agree that the
On Tue, 3 Oct 2017, Pavel Machek wrote:
> > This point I don't understand. What exactly do you mean?
>
> Hibernation:
>
> We freeze, do system snapshot, unfreeze, and write image to
> disk.
Where/why do you unfreeze between creating the snapshot and writing it
out?
Again, I agree that the
On Tue, Oct 03, 2017 at 08:21:42PM +, Bart Van Assche wrote:
> On Tue, 2017-10-03 at 22:17 +0200, Jiri Kosina wrote:
> > On Tue, 3 Oct 2017, Bart Van Assche wrote:
> > > What about the many drivers outside filesystems that use the
> > > set_freezable() / try_to_freeze() /
On Tue, Oct 03, 2017 at 08:21:42PM +, Bart Van Assche wrote:
> On Tue, 2017-10-03 at 22:17 +0200, Jiri Kosina wrote:
> > On Tue, 3 Oct 2017, Bart Van Assche wrote:
> > > What about the many drivers outside filesystems that use the
> > > set_freezable() / try_to_freeze() /
On Tue, 3 Oct 2017, Bart Van Assche wrote:
> If just a single driver would use that API to prevent that I/O occurs while
> processes are frozen then this patch will break that driver. I would like to
> know your opinion about the following patch in particular: "[PATCH v4 1/7] md:
> Make md resync
On Tue, 3 Oct 2017, Bart Van Assche wrote:
> If just a single driver would use that API to prevent that I/O occurs while
> processes are frozen then this patch will break that driver. I would like to
> know your opinion about the following patch in particular: "[PATCH v4 1/7] md:
> Make md resync
On Tue, 2017-10-03 at 22:17 +0200, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Bart Van Assche wrote:
> > What about the many drivers outside filesystems that use the
> > set_freezable() / try_to_freeze() / wait_event_freezable() API?
>
> Many/most of them are just completely bogus and pointless.
On Tue, 2017-10-03 at 22:17 +0200, Jiri Kosina wrote:
> On Tue, 3 Oct 2017, Bart Van Assche wrote:
> > What about the many drivers outside filesystems that use the
> > set_freezable() / try_to_freeze() / wait_event_freezable() API?
>
> Many/most of them are just completely bogus and pointless.
Hi!
> > Can memory management doing background writes be a problem?
>
> This point I don't understand. What exactly do you mean?
Hibernation:
We freeze, do system snapshot, unfreeze, and write image to
disk. Memory management wakes up (this used to be called bdflush),
decides its time to write
Hi!
> > Can memory management doing background writes be a problem?
>
> This point I don't understand. What exactly do you mean?
Hibernation:
We freeze, do system snapshot, unfreeze, and write image to
disk. Memory management wakes up (this used to be called bdflush),
decides its time to write
On Tue, 3 Oct 2017, Bart Van Assche wrote:
> What about the many drivers outside filesystems that use the
> set_freezable() / try_to_freeze() / wait_event_freezable() API?
Many/most of them are just completely bogus and pointless. I've killed a
lot of those in the past, but the copy/paste
On Tue, 3 Oct 2017, Bart Van Assche wrote:
> What about the many drivers outside filesystems that use the
> set_freezable() / try_to_freeze() / wait_event_freezable() API?
Many/most of them are just completely bogus and pointless. I've killed a
lot of those in the past, but the copy/paste
On Tue, 3 Oct 2017, Pavel Machek wrote:
> Can knfsd be a problem?
It'd actually be useful to walk through all the 'try_to_freeze()'
instances in kthreads, and analyze those. I've started this effort, and as
a result I removed most of them; but there are still quite a few
remaining. And knfsd
On Tue, 3 Oct 2017, Pavel Machek wrote:
> Can knfsd be a problem?
It'd actually be useful to walk through all the 'try_to_freeze()'
instances in kthreads, and analyze those. I've started this effort, and as
a result I removed most of them; but there are still quite a few
remaining. And knfsd
On Tue, 2017-10-03 at 11:53 -0700, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Many subsystems use system_freezable_wq and/or
On Tue, 2017-10-03 at 11:53 -0700, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Many subsystems use system_freezable_wq and/or
On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Are you surely-sure? You mentioned other in kernel sources of writes;
what about
On Tue 2017-10-03 11:53:13, Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
Are you surely-sure? You mentioned other in kernel sources of writes;
what about
On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
>
> Signed-off-by: Luis R. Rodriguez
I like
On Tuesday, October 3, 2017 8:53:13 PM CEST Luis R. Rodriguez wrote:
> Now that all filesystems which used to rely on kthread
> freezing have been converted to filesystem freeze/thawing
> we can remove the kernel kthread freezer.
>
> Signed-off-by: Luis R. Rodriguez
I like this one. :-)
Now that all filesystems which used to rely on kthread
freezing have been converted to filesystem freeze/thawing
we can remove the kernel kthread freezer.
Signed-off-by: Luis R. Rodriguez
---
Documentation/power/freezing-of-tasks.txt | 9 --
drivers/xen/manage.c
Now that all filesystems which used to rely on kthread
freezing have been converted to filesystem freeze/thawing
we can remove the kernel kthread freezer.
Signed-off-by: Luis R. Rodriguez
---
Documentation/power/freezing-of-tasks.txt | 9 --
drivers/xen/manage.c | 6
56 matches
Mail list logo