Re: [OMPI devel] vt compiler warnings and errors
Hi Everbody, we discussed this issue here a lot. Indeed, we were putting the contents of the VampirTrace tarball to the trunk (via the vendor branch stuff). Then again, this is no virtue by itself, is it? So we agree to removing the configure scripts from the SVN and having it created by the autogen script. This might resolve possible problems because of differing autoconf versions etc. See/hear you at the telco, Andreas On Friday 01 February 2008, Jeff Squyres wrote: > On Feb 1, 2008, at 5:35 AM, Ralf Wildenhues wrote: > > These files do not belong in SVN, they are generated by aclocal: > > ompi/contrib/vt/vt/extlib/otf/aclocal.m4 > > ompi/contrib/vt/vt/aclocal.m4 > > I think both of these have their own configure scripts, meaning that > they were autoconfed/automaked/whatever before they were put into OMPI. > > And in hindsight, this fits in with exactly what our original goal > was: take a VT tarball and dump it into OMPI's SVN. Doh! > > So I think the question still remains: can we hook VT's autoconf (et > al.) requirements into the top-level autogen.sh so that the trunk copy > of vt doesn't have configure/aclocal.m4/etc. and OMPI's top-level > autogen.sh will create them? -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] xensocket - callbacks through OPAL/libevent
On Mon, 4 Feb 2008, Muhammad Atif wrote: I am trying to port xensockets to openmpi. In principle, I have the framework and everything, but there seems to be a small issue, I cannot get libevent (or OPAL) to give callbacks for receive (or send) for xensockets. I have tried to implement native code for xensockets with libevent library, again the same issue. No call backs! . With normal sockets, callbacks do come easily. So question is, do the socket/file descriptors have to have some special mechanism attached to them to support callbacks for libevent/opal? i.e some structure/magic?. i.e. maybe the developers of xensockets did not add that callback/interrupt thing at the time of creation. Xensockets is open source, but my knowledge about these issues is limited. So I though some pointer in right direction might be useful. Yes and no :). As you discovered, the OPAL interface just repackages a library called libevent to handle its socket multiplexing. Libevent can use a number of different mechanisms to look for activity on sockets, including select() and poll() calls. On Linux, it will generally use poll(). poll() requires some kernel support to do its thing, so if Xensockets doesn't implement the right magic to trigger poll() events, then libevent won't work for Xensockets. There's really nothing you can do from the Open MPI front to work around this issue -- it would have to be fixed as part of Xensockets. Second question is, what if we cannot have the callbacks. What is the recommended way to implement the btl component for such a device? Do we need to do this with event timers? Have a look at any of the BTLs that isn't TCP -- none of them use libevent callbacks for progress. Instead, they provide a progress function as part of the BTL interface, which is called on a regular basis whenever progress needs to be made. Brian
Re: [OMPI devel] VT in trunk + how to disable
Hi Josh, hi everybody, we'd like to have VampirTrace enabled by default -- well, of course we do ;) Our main reason is the potential users: As soon as they want to use our tool they want to use it with the same configuration as the default Open MPI installation. Making the administrator re-install it at this point would be most inconvenient. If you're _not_ using our tools, you will _not_ see any difference at all while using the Open MPI installation or running your MPI program. And regarding configuration and compilation of Open MPI itself, we try hard to make everything robust and smooth. As there is no one insisting in disabled by default, we'd like to keep it enabled by default. I hope this is ok with everybody. Best regards, Andreas -- Dipl. Math. Andreas Knuepfer, Center for Information Services and High Performance Computing (ZIH), TU Dresden, Willersbau A114, Zellescher Weg 12, 01062 Dresden phone +49-351-463-38323, fax +49-351-463-37773 signature.asc Description: This is a digitally signed message part.
Re: [OMPI devel] VT in trunk + how to disable
I don't mind enabled by default - however, with a big caveat that we fix the build system issues. With that proviso, "on" by default is fine with me. On 2/5/08 9:00 AM, "Andreas Knüpfer" wrote: > Hi Josh, hi everybody, > > we'd like to have VampirTrace enabled by default -- well, of course we do ;) > > Our main reason is the potential users: As soon as they want to use our tool > they want to use it with the same configuration as the default Open MPI > installation. Making the administrator re-install it at this point would be > most inconvenient. > > If you're _not_ using our tools, you will _not_ see any difference at all > while using the Open MPI installation or running your MPI program. > > And regarding configuration and compilation of Open MPI itself, we try hard to > make everything robust and smooth. > > As there is no one insisting in disabled by default, we'd like to keep it > enabled by default. I hope this is ok with everybody. > > Best regards, Andreas >
[OMPI devel] cpu stride and offset for processor binding
Hi all,
I am trying to implement something in the paffinity:solaris that would
allow me to specify the cpu id with striding (aka in a sequence) when
selecting which cpu ids to bind. e.g. For a cpu set that looks like
this: { 0 1 2 3 4 5 6 7 }, and stride is to 2, and offset is to 1 (which
means start at pos 1), then ranks will bind to the cpus in the following
order: { 1 3 5 7 2 4 6 0 }. The obvious intent is to take advantage of
the perf by allocating the ranks in a certain order on multi-core systems.
But then we realized this may be implemented elsewhere outside the
solaris paffinity code. I see something in trac #1023 that may allow me
to specify a cpuid or cores in a range but it doesn't seem to allow me
specify the cpu id to bind in strides. And with that, rank specification
may seem to be doable, but I may end up entering a long list of cpu ids
in strides manually, if the machine happens to have many cpus. Plus
another down side is that Solaris doesn't seem to have stable interface
for me to extract out the core/socket information from the kernel. So
striding might be the only way for me to go for now.
Is there some unspoken feature that's coming down the pipe that may
allow me to specify cpuids in a sequence, or we already have some
feature like that that I didn't know about? I look around but I don't
see anything like this.
Thanks in advance for any comments.
--
- Pak Lui
pak@sun.com
Re: [OMPI devel] cpu stride and offset for processor binding
I would think that the syntax being implemented by Voltaire could be
extended to support this need, but I'll leave that up to them for comment.
On 2/5/08 5:01 PM, "Pak Lui" wrote:
> Hi all,
>
> I am trying to implement something in the paffinity:solaris that would
> allow me to specify the cpu id with striding (aka in a sequence) when
> selecting which cpu ids to bind. e.g. For a cpu set that looks like
> this: { 0 1 2 3 4 5 6 7 }, and stride is to 2, and offset is to 1 (which
> means start at pos 1), then ranks will bind to the cpus in the following
> order: { 1 3 5 7 2 4 6 0 }. The obvious intent is to take advantage of
> the perf by allocating the ranks in a certain order on multi-core systems.
>
> But then we realized this may be implemented elsewhere outside the
> solaris paffinity code. I see something in trac #1023 that may allow me
> to specify a cpuid or cores in a range but it doesn't seem to allow me
> specify the cpu id to bind in strides. And with that, rank specification
> may seem to be doable, but I may end up entering a long list of cpu ids
> in strides manually, if the machine happens to have many cpus. Plus
> another down side is that Solaris doesn't seem to have stable interface
> for me to extract out the core/socket information from the kernel. So
> striding might be the only way for me to go for now.
>
> Is there some unspoken feature that's coming down the pipe that may
> allow me to specify cpuids in a sequence, or we already have some
> feature like that that I didn't know about? I look around but I don't
> see anything like this.
>
> Thanks in advance for any comments.
