[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200707102045.17101.a1426z@gawab.com>
Date: Tue, 10 Jul 2007 20:45:17 +0300
From: Al Boldi <a1426z@...ab.com>
To: Jeremy Fitzhardinge <jeremy@...p.org>,
Jeremy Maitin-Shepard <jbms@....edu>
Cc: Pavel Machek <pavel@....cz>, Nick Piggin <nickpiggin@...oo.com.au>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Hibernation Redesign
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 is proposing. The kernel-internal
> interfaces we've put in place to make Xen work could be reused to do
> some of the things you're talking about. In particular, a kernel
> running under Xen has to be able to deal with non-contiguous physical
> pages, and reusing the same pagetable hooks would allow a kexeced kernel
> to run happily out of any random assortment of pages you manage to
> allocate for it.
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 point out that there is no need to maintain two
separate kernels, much like Xen, which inlines two modes into the kernel:
host and guest.
So kexec really seems the way to go, which mimics the way APM used to do it,
which is known to work flawlessly with minimal OS involvement.
Thanks!
--
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists