Rafael J. Wysocki wrote:
The only direct relationship between the freezer and drivers is that some of
them use kernel threads that call try_to_freeze() (and other freezer-related
functions).
If removing thoset was the only benefit of getting rid of the freezer
with kexec, it would almost be wo
> > > > Freezing of tasks is slowing down suspend. Don't know how serious
> > > > this is, suspend is pretty fast, but could possibly be even faster.
> > >
> > > It's FUD. Freezing of tasks normally takes next to no time. I've never
> > > understood the rediculously long timeout it has. If freez
Hi!
> > > Freezing of tasks is slowing down suspend. Don't know how serious
> > > this is, suspend is pretty fast, but could possibly be even faster.
> >
> > It's FUD. Freezing of tasks normally takes next to no time. I've never
> > understood the rediculously long timeout it has. If freezing s
Al Boldi <[EMAIL PROTECTED]> writes:
> Mark Lord wrote:
>> Jeremy Maitin-Shepard wrote:
>> > I'll certainly admit the kexec idea is vaporware currently,
> Your idea is starting to become a reality with this thread:
> "[PATCH 0/2] Kexec jump: The first step to kexec base hibernation"
Someone else
On Thursday, 12 July 2007 01:12, Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 12 July 2007 00:17, Al Boldi wrote:
> > > Mark Lord wrote:
> > > > Jeremy Maitin-Shepard wrote:
> > > > > I'll certainly admit the kexec idea is vaporware currently,
> > >
> > > Your idea is starting to bec
Nigel Cunningham wrote:
> You'll see from the above numbers that the freezer is not nearly as
> intrusive as you were thinking (~10% of what you wrote above). It is
> limited to code related to kernel threads, and then to either setting a
> flag when the thread is started to say "I don't need to be
Hi.
On Wednesday 11 July 2007 23:16:41 Jeremy Maitin-Shepard wrote:
> Nigel Cunningham <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > No other _proper_ solutions have been proposed. Everyone who suggests
removing
> > the freezer also suggests implementing it all over again. It might be
sending
Hi.
On Thursday 12 July 2007 09:12:24 Al Boldi wrote:
> Rafael J. Wysocki wrote:
> > On Thursday, 12 July 2007 00:17, Al Boldi wrote:
> > > Mark Lord wrote:
> > > > Jeremy Maitin-Shepard wrote:
> > > > > I'll certainly admit the kexec idea is vaporware currently,
> > >
> > > Your idea is starting
Rafael J. Wysocki wrote:
> On Thursday, 12 July 2007 00:17, Al Boldi wrote:
> > Mark Lord wrote:
> > > Jeremy Maitin-Shepard wrote:
> > > > I'll certainly admit the kexec idea is vaporware currently,
> >
> > Your idea is starting to become a reality with this thread:
> > "[PATCH 0/2] Kexec jump: Th
Hi.
On Thursday 12 July 2007 03:55:40 [EMAIL PROTECTED] wrote:
> On Wed, 11 Jul 2007, Nigel Cunningham wrote:
>
> > Hi.
> >
> > On Wednesday 11 July 2007 21:11:34 Miklos Szeredi wrote:
> >>> Anyway, to implement the kexec approach we must separate the
> >>> hibernation from the suspend at the dri
On Thursday, 12 July 2007 00:17, Al Boldi wrote:
> Mark Lord wrote:
> > Jeremy Maitin-Shepard wrote:
> > > I'll certainly admit the kexec idea is vaporware currently,
>
> Your idea is starting to become a reality with this thread:
> "[PATCH 0/2] Kexec jump: The first step to kexec base hibernation
Mark Lord wrote:
> Jeremy Maitin-Shepard wrote:
> > I'll certainly admit the kexec idea is vaporware currently,
Your idea is starting to become a reality with this thread:
"[PATCH 0/2] Kexec jump: The first step to kexec base hibernation"
> > but it does
> > differ in a significant way from freez
On Wednesday, 11 July 2007 22:48, Mark Lord wrote:
> Jeremy Maitin-Shepard wrote:
> >>
> > I'll certainly admit the kexec idea is vaporware currently, but it does
> > differ in a significant way from freezer-based approaches, such that I
> > don't think it should be referred to as just another impl
Hi,
On Wednesday, 11 July 2007 14:49, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 11 July 2007 22:19:10 Rafael J. Wysocki wrote:
> > The sync probably slows down more than the freezing itself ...
>
> Absolutely. Wy more. Maybe it would help if you popped in some printks
> that help peopl
On Wednesday, 11 July 2007 14:29, Miklos Szeredi wrote:
> > > > > Freezing of tasks is slowing down suspend. Don't know how serious
> > > > > this is, suspend is pretty fast, but could possibly be even faster.
> > > >
> > > > It's FUD. Freezing of tasks normally takes next to no time. I've never
Jeremy Maitin-Shepard wrote:
I'll certainly admit the kexec idea is vaporware currently, but it does
differ in a significant way from freezer-based approaches, such that I
don't think it should be referred to as just another implementation of a
freezer. Specifically, it doesn't require that th
On Wed, 11 Jul 2007, Nigel Cunningham wrote:
Hi.
On Wednesday 11 July 2007 21:11:34 Miklos Szeredi wrote:
Anyway, to implement the kexec approach we must separate the
hibernation from the suspend at the drivers level, which I'm still
going to do, but I need to take part in endless discussions
Nigel Cunningham <[EMAIL PROTECTED]> writes:
[snip]
> No other _proper_ solutions have been proposed. Everyone who suggests
> removing
> the freezer also suggests implementing it all over again. It might be sending
> SIGSTOP to everything. It might be shifting the desk chairs around and
> cre
> The point to freezing tasks isn't just to stop drivers doing work. It's also
> to stop userspace doing work and thereby increase reliability. The more work
> that is occuring while we're trying to write a hibernation image, the less
> reliable the hibernation will be (competing for memory and
Hi.
On Wednesday 11 July 2007 22:19:10 Rafael J. Wysocki wrote:
> The sync probably slows down more than the freezing itself ...
Absolutely. Wy more. Maybe it would help if you popped in some printks
that help people see that it's not the freezer taking a long time, but
syncing?
Nigel
p
Hi.
On Wednesday 11 July 2007 22:24:04 Miklos Szeredi wrote:
> > No other _proper_ solutions have been proposed. Everyone who suggests
removing
> > the freezer also suggests implementing it all over again. It might be
sending
> > SIGSTOP to everything. It might be shifting the desk chairs arou
> > > > Freezing of tasks is slowing down suspend. Don't know how serious
> > > > this is, suspend is pretty fast, but could possibly be even faster.
> > >
> > > It's FUD. Freezing of tasks normally takes next to no time. I've never
> > > understood the rediculously long timeout it has. If freez
> No other _proper_ solutions have been proposed. Everyone who suggests
> removing
> the freezer also suggests implementing it all over again. It might be sending
> SIGSTOP to everything. It might be shifting the desk chairs around and
> creating a completely new kernel context, but they always
On Wednesday, 11 July 2007 14:09, Miklos Szeredi wrote:
> > > Freezing of tasks is slowing down suspend. Don't know how serious
> > > this is, suspend is pretty fast, but could possibly be even faster.
> >
> > It's FUD. Freezing of tasks normally takes next to no time. I've never
> > understood
Hi.
On Wednesday 11 July 2007 22:09:39 Miklos Szeredi wrote:
> > > Freezing of tasks is slowing down suspend. Don't know how serious
> > > this is, suspend is pretty fast, but could possibly be even faster.
> >
> > It's FUD. Freezing of tasks normally takes next to no time. I've never
> > under
On Wednesday, 11 July 2007 13:54, Miklos Szeredi wrote:
> > > > regarding the freezer, how it is bad and how we should drop it,
> > > > because it breaks things (which NB is not true, because it doesn't).
> > >
> > > This thread started out from a bug, that seemed to be caused by the
> > > freezer
Hi.
On Wednesday 11 July 2007 21:11:34 Miklos Szeredi wrote:
> > Anyway, to implement the kexec approach we must separate the
> > hibernation from the suspend at the drivers level, which I'm still
> > going to do, but I need to take part in endless discussions
>
> Discussions are good. We unders
> > Freezing of tasks is slowing down suspend. Don't know how serious
> > this is, suspend is pretty fast, but could possibly be even faster.
>
> It's FUD. Freezing of tasks normally takes next to no time. I've never
> understood the rediculously long timeout it has. If freezing succeeds, all
>
Hi.
On Wednesday 11 July 2007 21:54:58 Miklos Szeredi wrote:
> Freezing of tasks is slowing down suspend. Don't know how serious
> this is, suspend is pretty fast, but could possibly be even faster.
It's FUD. Freezing of tasks normally takes next to no time. I've never
understood the rediculous
> > > regarding the freezer, how it is bad and how we should drop it,
> > > because it breaks things (which NB is not true, because it doesn't).
> >
> > This thread started out from a bug, that seemed to be caused by the
> > freezer (we still don't exactly know what it was caused by), and the
> >
On Wednesday, 11 July 2007 13:11, Miklos Szeredi wrote:
> > Anyway, to implement the kexec approach we must separate the
> > hibernation from the suspend at the drivers level, which I'm still
> > going to do, but I need to take part in endless discussions
>
> Discussions are good. We understand t
> Anyway, to implement the kexec approach we must separate the
> hibernation from the suspend at the drivers level, which I'm still
> going to do, but I need to take part in endless discussions
Discussions are good. We understand the problem better. Now I still
think we don't understand every as
On Wednesday, 11 July 2007 12:42, Miklos Szeredi wrote:
> > > > Yes, I suppose. You're certain the old kernel's devices are completely
> > > > quiescent at that point?
> > >
> > > That's exactly the problem; trying to save a state from within the
> > > kernel would probably necessitate a freezer
> > > Yes, I suppose. You're certain the old kernel's devices are completely
> > > quiescent at that point?
> >
> > That's exactly the problem; trying to save a state from within the
> > kernel would probably necessitate a freezer hack, which we are
> > trying so dearly to avoid.
>
> Well, I don
On Wednesday, 11 July 2007 06:11, Al Boldi wrote:
> Jeremy Fitzhardinge wrote:
> > Jeremy Maitin-Shepard wrote:
> > > In
> > > addition, I recall that the Linux boot procedure on x86 and on some
> > > other platforms necessarily uses certain low-address memory, like the
> > > first 640K, which mu
Jeremy Fitzhardinge wrote:
> Jeremy Maitin-Shepard wrote:
> > In
> > addition, I recall that the Linux boot procedure on x86 and on some
> > other platforms necessarily uses certain low-address memory, like the
> > first 640K, which must be backed up regardless.
>
> Well, the traditional framebuf
Jeremy Maitin-Shepard wrote:
I suppose that would be an interesting thing to look into. Another
possible approach for having the kernel run in non-contiguous memory is
to specify a memmap exactly to the kernel on the command-line, as I
believe is done for the crashdump kernels currently.
That
Al Boldi <[EMAIL PROTECTED]> writes:
[snip]
> Exactly, there may well be overlap between Xen and the kexec hibernate
> approach, for which code structures should definitely be leveraged.
> And, I wasn't suggesting to use Xen as an HV, which wouldn't really solve
> anything, but was trying to p
Jeremy Fitzhardinge wrote:
> Jeremy Maitin-Shepard wrote:
> > I don't know a whole lot about xen, but it seems that one issue with
> > this approach is that it requires you run your system under a hypervisor
> > at all times, which may introduce some overhead.
>
> No, I don't think that's what Al i
Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> I don't know a whole lot about xen, but it seems that one issue with
>> this approach is that it requires you run your system under a hypervisor
>> at all times, which may introduce some overhead.
>>
> No, I don't
Jeremy Maitin-Shepard wrote:
I don't know a whole lot about xen, but it seems that one issue with
this approach is that it requires you run your system under a hypervisor
at all times, which may introduce some overhead.
No, I don't think that's what Al is proposing. The kernel-internal
int
Al Boldi <[EMAIL PROTECTED]> writes:
[snip]
> Who said we need two kernels? You could inline it like Xen, which would give
> you one kernel with two modes: normal and hibernate.
I don't know a whole lot about xen, but it seems that one issue with
this approach is that it requires you run your
Al Boldi wrote:
Pavel Machek wrote:
In the end, you'll get rid of freezer problems, but will have two
kernels to care about, and certainly more conventional design. I do
not think I have time to try that (and don't think freezer problems
are _that_ bad in the first place), but some interested
Pavel Machek wrote:
> > >>from a *new* kernel space/user space that is created by loading a new
> > >>kernel in a manner similar to what is done for kexec crashdumps.
> > >> Unlike kexec crashdumps, however, it would not require reserving any
> > >> memory at boot, because the necessary memory (ma
Oliver Neukum <[EMAIL PROTECTED]> writes:
> Am Montag, 9. Juli 2007 schrieb Jeremy Maitin-Shepard:
>> Oliver Neukum <[EMAIL PROTECTED]> writes:
>>
>> [snip]
>>
>> > Hm, once the new kernel is booted, this decision is irrevocable, isn't it?
>> > Is there any way to deal with errors by handing con
Am Montag, 9. Juli 2007 schrieb Jeremy Maitin-Shepard:
> Oliver Neukum <[EMAIL PROTECTED]> writes:
>
> [snip]
>
> > Hm, once the new kernel is booted, this decision is irrevocable, isn't it?
> > Is there any way to deal with errors by handing control back?
>
> Returning to the old kernel can be
Oliver Neukum <[EMAIL PROTECTED]> writes:
[snip]
> Hm, once the new kernel is booted, this decision is irrevocable, isn't it?
> Is there any way to deal with errors by handing control back?
Returning to the old kernel can be done by telling drivers to set the
hardware to the appropriate state, t
Am Montag, 9. Juli 2007 schrieb Pavel Machek:
> Hi!
>
> > >> This approach eliminates the need for the freezer, as it would make
> > >> hibernate look a lot a bit like suspend to ram from the perspective of
> > >> the "old" kernel (the kernel being hibernated), as the hibernate
> > >> operation it
Hi!
> >>from a *new* kernel space/user space that is created by loading a new
> >>kernel in a manner similar to what is done for kexec crashdumps. Unlike
> >>kexec crashdumps, however, it would not require reserving any memory at
> >>boot, because the necessary memory (maybe 16MB or 64MB) can be
Hi!
> >> This approach eliminates the need for the freezer, as it would make
> >> hibernate look a lot a bit like suspend to ram from the perspective of
> >> the "old" kernel (the kernel being hibernated), as the hibernate
> >> operation itself would be completely atomic from the perspective of th
Jeremy Maitin-Shepard wrote:
It would indeed be a pain for the new kernel to be loaded and have to
use discontiguous memory. The trick is, though, that this is not
necessary. Immediately before jumping to the new kernel, the first X
bytes (where X is the amount of memory the new kernel will get
Nick Piggin wrote:
Jeremy Maitin-Shepard wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Yes, I have a rough idea about how page reclaim works. But I just
mean it would not be trivial to load the new kernel into physically
discontiguous memory. Possible of course, but I don't think kexec or
Jeremy Maitin-Shepard wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Yes, I have a rough idea about how page reclaim works. But I just
mean it would not be trivial to load the new kernel into physically
discontiguous memory. Possible of course, but I don't think kexec or
the setup code could q
Nick Piggin <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>>> This is the Morton method, isn't it? :) I remember it sounding like a
>>> very good idea when he brought it up, but I can't remember the details
>>> of why it was rejected or what
Jeremy Maitin-Shepard wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
This is the Morton method, isn't it? :) I remember it sounding like a
very good idea when he brought it up, but I can't remember the details
of why it was rejected or what the problems were.
Perhaps he did bring it up befo
Nick Piggin wrote:
Jeremy Maitin-Shepard wrote:
Al Boldi <[EMAIL PROTECTED]> writes:
Pavel Machek wrote:
We are stuck with refrigerator for now, and at least for hibernation,
I don't see any feasible alternative.
Feasible alternative?
I posted such an alternative to the list a sho
Nick Piggin <[EMAIL PROTECTED]> writes:
> Jeremy Maitin-Shepard wrote:
>> Al Boldi <[EMAIL PROTECTED]> writes:
>>
>>
>>> Pavel Machek wrote:
>>>
We are stuck with refrigerator for now, and at least for hibernation,
I don't see any feasible alternative.
>>
>>
>>> Feasible alternative
Jeremy Maitin-Shepard wrote:
Al Boldi <[EMAIL PROTECTED]> writes:
Pavel Machek wrote:
We are stuck with refrigerator for now, and at least for hibernation,
I don't see any feasible alternative.
Feasible alternative?
I posted such an alternative to the list a short time ago: hibenratin
Al Boldi <[EMAIL PROTECTED]> writes:
> Pavel Machek wrote:
>> We are stuck with refrigerator for now, and at least for hibernation,
>> I don't see any feasible alternative.
> Feasible alternative?
I posted such an alternative to the list a short time ago: hibenrating
from a *new* kernel space/us
Pavel Machek wrote:
> We are stuck with refrigerator for now, and at least for hibernation,
> I don't see any feasible alternative.
Feasible alternative?
Freezing is the only way to successfully suspend, in kernel space that is.
The problem here is: Why do we freeze in kernel space?
APM didn'
60 matches
Mail list logo
