Re: [TuxOnIce-devel] [RFC] TuxOnIce

[Nigel Cunningham]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/