From: Vincentius Robby (vincentius_at_umich_dot_edu)
Date: Wed Jul 30 2008 - 07:48:39 PDT
Hello,
Thank you for your help. I am currently checking out your suggestions.
I am looking for a checkpointing software to be attached to a Linux
2.6 kernel running on SPARC V8. I will send further questions that I
encounter.
--
Vincentius Robby
University of Michigan
Quoting "Paul H. Hargrove" <PHHargrove_at_lbl_dot_gov>:
> In both the BLCR kernel and user-space code we make use of atomic
> counters for various purposes, including a reader-writer sort of
> lock in the user space code. In all architectures we've supported
> so far we've had support for atomic operations on 32-bit integers.
> However, on SPARC revisions prior to "SPARC V8+" (UltraSPARC) the
> only support for atomics is via spinlocks. The spinlock approach
> can work in the kernel because one can block interrupts. In
> user-space, however, the spinlock approach can lead to deadlock in
> the presence of signal handlers. So, I believe that it is either
> impossible or impractical to port BLCR to chips older than
> UltraSPARC. (I am willing to be proven wrong, but am strongly
> discouraging you from trying for older cpus as I think success is
> unlikely)
>
> Except for the atomic-ops issue above, I am not aware of a "major
> hindrance" for a SPARC port of BLCR, but we don't have the resources
> (either people time or machines) to do it ourselves. For somebody
> with understanding of the SPARC platform (including ASM and ABI
> issues), we should be able to provide the guidance to perform a port.
>
> The "vmadump" directory contains support only for 2.4.X kernels, and
> is being dropped from BLCR (kept only for RH9 and RHEL kernels in
> blcr-0.7.X and will be removed entirely by the time 0.8.X is
> released). The original BProc/VMADump code did support SPARC,
> though I have no idea if that was well tested or not. When
> BProc/VMADump was ported to the 2.6.X kernels, the SPARC platform
> code was apparently not ported. This was most likely due to a
> combination of lack of time and lack of interest.
>
> The steps for a BLCR port are:
> 1) vmadump4/vmadump_<ARCH>.c, with additions to vmadump.h if needed.
> This should hopefully just be a straight-forward port of the
> older vmadump code. However, the 2.4.x vs. 2.6.x differences may be
> non-trivial. Additionally, BLCR supports pthreads, which the
> original VMADump did not, and this requires that the ABI's
> thread-specific data pointers be dealt wth properly, which the
> exisiting VMADump code might not do.
> 2) include/blcr_ksyms.h needs the right inline ASM bits for linker info
> 3) cr_module/arch/<ARCH>/cr_arch.h needs a couple of inline
> functions which can probably be found in the vmadump code.
> 4) libcr/arch/<ARCH>/cr_{arch,atomic}.h needs inline ASM for system
> calls and atomic operations, plus ASM for a simple signal handler.
> All these things should be present in glibc's source code somewhere.
> DO NOT cut-and-paste any of this stuff from the Linux kernel (the
> kernel is GPL and the code in libcr is LGPL)
>
> Without knowing your own level if familiarity with the SPARC
> platform, I cannot estimate the time this port would take. However,
> I can say that I will be available to provide some guidance with the
> various inline ASM pieces.
>
> -Paul
>
> Vincentius Robby wrote:
>> Hello,
>>
>> What is the major hindrance in porting BLCR to sparc? and does the
>> vmadump component support sparc already? (it is listed in one of
>> the comments in ./vmadump/ but I see no comment saying so in
>> ./vmadump4/)
>>
>> Thanks.
>>
>
>
> --
> Paul H. Hargrove PHHargrove_at_lbl_dot_gov
> Future Technologies Group HPC Research Department
> Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
>
>
>