lkml.org 
[lkml]   [2010]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ksummit-2010-discuss] checkpoint-restart: naked patch
Hello, Matt.

On 11/17/2010 11:17 PM, Matt Helsley wrote:
>> It may be harder but those will be localized for specific features
>> which would be useful for other purposes too. With in-kernel CR,
>> you're adding a bunch of intrusive changes which can't be tested or
>> used apart from CR.
>
> You seem to be arguing "Z is only testable/useful for doing the things Z
> was made for". I couldn't agree more with that. CR is useful for:

I'm saying it's way too narrow scoped and inflexible to be a kernel
feature. Kernel features should be like the basic tools, you know,
hammers, saws, drills and stuff. In-kernel CR is more like an over
complicated food processor which usually sits in the top drawer after
first several runs,

> Fault-tolerance (typical HPC)
> Load-balancing (less-typical HPC)
> Debugging (simple [e.g. instead of coredumps] or complex
> time-reversible)
> Embedded devices that need to deal with persistent low-memory
> situations.

which can do all of the above, a lot of which can be achieved in
less messy way than putting the whole thing inside the kernel.

> My personal favorite idea (that hasn't been implemented yet) is an
> application startup cache. I've been wondering if caching bash startup
> after all the shared libraries have been searched, loaded, and linked
> couldn't save a bunch of time spent in shell scripts. Post-link actually
> seems like a checkpoint in application startup which would be generally
> useful too. Of course you'd want to flush [portions of] the cache when
> packages get upgraded/removed or shell PATHs change and the caches
> would have to be per-user.

What does that have anything to do with the kernel? If you want
post-link cache, implement it in ld.so where it belongs. That's like
using food processor to mix cement.

> I'm less confident but still curious about caching after running rc
> scripts (less confident because it would depend highly on the content
> of the rc scripts). A scripted boot, for example, might be able to save
> some time if the same rc scripts are run and they don't vary over time.
> That in turn might be useful for carefully-tuned boots on embedded devices.
>
> That said we don't currently have code for application caching. Yet we
> can't be expected to write tools for every possible use of our API in
> order to show just how true your tautology is.

Continuing the same line of thought. It _CAN_ be used to do that in a
convoluted way but there are better ways to solve those problems.

> Most of the time, in fact, the fields we output are there only because
> they reflect the 'model' of how things work that the kernel presents to
> userspace. That model also rarely changes (we've never gotten rid of the
> POSIX concept of process groups in one extreme example). Perhaps the
> closest thing we have to wholly-kernel-internal data structures are the
> signal/sighand structs which echo the way these fields are split from the
> task struct and shared between tasks. Though I'd argue that gets back into
> the 'model' presented to userspace (via fork/clone) anyway...

Yeah, exactly, so just do it inside the established ABI extending
where it makes sense. No reason to add a whole separate set.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2010-11-18 11:09    [W:0.178 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site