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

On Sat, 6 Nov 2010, Matt Helsley wrote:

Yes, our patches touch a wide variety of kernel code. You have just failed
to appreciate how "wide" the kernel ABI truly is. You can't really count
it by number of syscalls, number of pseudo-filesystems, etc. There's
also the intended behavior of those interfaces to consider. Each piece
of checkpoint/restart code is relatively self-contained. This can be
confirmed merely by looking at many of the patches we've already posted
enabling checkpoint/restart of that feature. Until you've tried to
implement checkpoint/restart for an interface or until you've bothered
to review a patch for one of them (my favorite on is eventfd:
http://www.mail-archive.com/devel@xxxxxxxxxx/msg21565.html ) please
don't tell us it's too complex. Then compare that with your proposed
ghastly stack of userspace cards -- ptrace (really more like strace) +
LD_PRELOAD + a daemon...

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.

Please, do not compare things like single file systems, drivers, or
otherwise fairly isolated components, with this "thing".
This thing touches a freaky-large number of subsystems, effectively
adding a glueage between them, which can might end up causing problems
(and/or restrict design choices) in the future.
The naked patch looks like just a sugar coating to me, which left out 300+
lines of extra logic in epoll alone.
This is one of the widest, deepest, intrusive patches I have seen in a
while, whose inclusion would require a little bit more than handwaving and
continuous re-posting IMO.



- Davide


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

Relevant Pages

  • Re: Kernel-loadable Root Kits
    ... But activity in /tmp is normal and will be ignored by tripwire, ... >> appropriate lock in kernel code but I don't know if it's possible. ... >> and compare MD5 checksums. ... from;)) some time ago there were proprietary device drivers (sound cards, ...
    (FreeBSD-Security)
  • Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch
    ... If you've compared the performance of that kernel to your ... virtualization hardware then you already know how they compare. ... Also please remember that we're not implementing containers ... It's less than one of the simpler DRM graphics drivers -- i915: ...
    (Linux-Kernel)
  • Re: ACPI Error under 2.6.26-rc*
    ... and attach the rsdp for all of the three cases (good, ACPI Error, ... could you please attach the dmesg output of a 2.6.25.10 kernel which has ... # IPVS transport protocol load balancing support ... # Device Drivers ...
    (Linux-Kernel)
  • init_emergency_isa_pool calling mempool_create in non-sleeping context
    ... I just saw this when booting a current linux-2.6.git kernel. ... # Power management and ACPI options ... # Bus options (PCI etc.) ... # Enable WiMAX to see the WiMAX drivers ...
    (Linux-Kernel)
  • Re: 2.6.29+ NFS-Server Problem "reconnect_path: npd != pd"
    ... This is an x86_64 kernel. ... # Device Drivers ... # SCSI device support ...
    (Linux-Kernel)