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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
