lkml.org 
[lkml]   [2009]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [TuxOnIce-devel] [RFC] TuxOnIce
From
Date
Hi.

(Starting to catch up after a week away)

On Thu, 2009-05-14 at 11:16 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > And we have different ideas about how things should be done. Userspace
> > > > > vs kernel space. Providing tuning knobs vs not. And so on.
> > > >
> > > > This isn't _that_ important. Actually, I'm not against an entirely in-kernel
> > > > solution, as there are some clear benefits of doing it this way. We only
> > > > need to be careful enough not to break the existing setups.
> > >
> > > Would you elaborate?
> >
> > One benefit is that we need not anything in the initrd for hibernation to work.
> > Another one is that we can get superior performance, for obvious reasons
> > (less copying of data, faster I/O). Yet another is simpler configuration and
> > no need to maintain a separate set of user space tools. I probably could
> > find more.
> >
> > > I would really hate to put progressbar painting into kernel; and if
> > > that's in userspace, we can do compression/encryption there too as
> > > well....
> >
> > That's correct, we can. But since we have LZO in the kernel now, we can use
> > it for compression just as well, can't we?
>
> Yes, but we do not have progressbar painting in the kernel -- yet --
> so users will still need initrd etc.

Who does?

> Yes, we can move LZO into kernel pretty cheaply, and it will have
> minor benefit of slightly faster reguler swsusp, but...

LZO is already in the kernel (a cryptoapi module). The result won't be
slightly faster - it will be (assuming the CPU is fast enough) slightly
better than double the speed, on average.

Regards,

Nigel



\
 
 \ /
  Last update: 2009-05-17 01:13    [from the cache]
©2003-2011 Jasper Spaans