linux-kernel - Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4CD5360E.7060902@kernel.org>
Date:	Sat, 06 Nov 2010 12:03:42 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Matt Helsley <matthltc@...ibm.com>
CC:	Oren Laadan <orenl@...columbia.edu>,
	ksummit-2010-discuss@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch

Hello,

On 11/06/2010 11:12 AM, Matt Helsley wrote:
> If you think specialized hardware acceleration is necessary for
> containers then perhaps you have a poor understanding of what a container
> is. Chances are if you're running a container with namespaces configured
> then you're already paying the performance costs of running in a
> container. If you've compared the performance of that kernel to your
> virtualization hardware then you already know how they compare.

I was talking about virtualization when referring to hardware support.

> So please stop asserting that a purported lack of hardware support
> is significant. Also please remember that we're not implementing containers
> in this patch set -- they're already in.

Sure, that was my point.  So, let's drop the handwaving about being
transparent.

> Incidentally, 20k lines of code is less than many pieces of the kernel.
> It's less than many:
> 
> Filesystems (I've selected ones designed for rotating media or networks usually..)
> 	ext4, nfs, ocfs2, xfs, reiserfs, ntfs, gfs2, jfs, cifs, ubifs, nilfs2, btrfs
> 
> Non-filesystem file-system support code:
> 	nfsd, nls
> 
> It's less than one of the simpler DRM graphics drivers -- i915:
> 	$ cd drivers/gpu/drm/i915
> 	$ wc -l *.[ch]
> 	...
> 	41481 total
>
> It's less than any one of the lpfc, bfa, aic7xxx, qla2xxx, and mpt2sas
> drivers I see under scsi. Perhaps a more fair comparison might be to compare
> a single driver to a single checkpointable kernel interface but it's
> a more-fair comparison that skews even more in our favor.

Yeah, and imagine what people would say if ext4, or heaven forbid,
aic7xxx code was scattered all over the kernel.

> Yes, when you *add it all up* it's more than half the size of the kernel/
> directory. Bear in mind that the portions we add to kernel/checkpoint though
> are only 4603 lines long -- about the same size as many kernel/*.c files.
> The rest is for each kernel interface that adds/manipulates state we need to
> be able to checkpoint. Or arch code.. etc.
> 
> So please don't base your assessment of our code on your apparently
> flawed notion of containers nor on the summary line of a diffstat
> you saw.

I don't believe my notion of containers was or is flawed and already
said that the diffstat per-se didn't look too bad.  With enough
benefits, I wouldn't be opposed against the rather invasive changes.
It's just that the whole thing is conceived backwards and there are
already working alternatives which may be somewhat messy now but
nevertheless achieve about the same effect without the craziness of
serializing in-kernel data structures which are already mostly visible
to userland to begin with.

Thanks.

-- 
tejun
--
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/