On Wed, Nov 07, 2007 at 09:07:23PM -0700, Brian Barrett wrote:
> Personally, I'd rather just not mark MPI completion until a local
> completion callback from the BTL. But others don't like that idea, so
> we came up with a way for back pressure from the BTL to say "it's not
> on the wire yet
On Wed, Nov 07, 2007 at 01:16:04PM -0500, George Bosilca wrote:
>
> On Nov 7, 2007, at 12:51 PM, Jeff Squyres wrote:
>
>>> The same callback is called in both cases. In the case that you
>>> described, the callback is called just a little bit deeper into the
>>> recursion, when in the "normal case"
On Wed, Nov 07, 2007 at 11:25:43PM -0500, Patrick Geoffray wrote:
> Richard Graham wrote:
> > The real problem, as you and others have pointed out is the lack of
> > predictable time slices for the progress engine to do its work, when relying
> > on the ULP to make calls into the library...
>
> Th
Hi,
I have a question that I shouldn't need to ask, but I'm
kind of lost in the code.
The btl sm component is using the circular buffers to write and read
fragments (sending and receiving).
In the write_to_head and read_from_tail I can only see pointers beeing set,
no data being moved. So
Whoa; I'm not sure we want to apply this.
All ROMIO patches *must* be coordinated with the ROMIO maintainers.
Otherwise this becomes a complete nightmare of logistics. There's
already a few other ROMIO patches that we have consciously chosen not
to apply because of the tangled issues that
On Thu, Nov 08, 2007 at 07:51:28AM -0500, Jeff Squyres wrote:
[r16691]
> Whoa; I'm not sure we want to apply this.
Me neither.
> All ROMIO patches *must* be coordinated with the ROMIO maintainers.
Upstream? That's the upstream patch.
Jiri Polach has extracted the fix for this problem. Updat
On Nov 8, 2007, at 7:57 AM, Adrian Knoth wrote:
All ROMIO patches *must* be coordinated with the ROMIO maintainers.
Upstream? That's the upstream patch.
That was extracted from ROMIO itself? Which release?
Jiri Polach has extracted the fix for this problem. Updating OMPI to a
newer ROMIO
George Bosilca wrote:
On Nov 6, 2007, at 8:38 AM, Terry Dontje wrote:
George Bosilca wrote:
If I understand correctly your question, then we don't need any
extension. Each request has a unique ID (from PERUSE perspective).
However, if I remember well this is only half implemented in our
PERUS
I literally just discovered that the trac "milestone" pages can be
edited.
This seems like a much better place to put the 1.1, 1.2, and 1.3
release series wiki pages. So I moved all the content and updated the
links on the front wiki page. Each "1.x" milestone is now a top-level
view of
On 11/8/07 4:03 AM, "Gleb Natapov" wrote:
> On Wed, Nov 07, 2007 at 11:25:43PM -0500, Patrick Geoffray wrote:
>> Richard Graham wrote:
>>> The real problem, as you and others have pointed out is the lack of
>>> predictable time slices for the progress engine to do its work, when relying
>>> on
Thanks Jeff!
On Nov 8, 2007 9:07 AM, Jeff Squyres wrote:
> I literally just discovered that the trac "milestone" pages can be
> edited.
>
> This seems like a much better place to put the 1.1, 1.2, and 1.3
> release series wiki pages. So I moved all the content and updated the
> links on the fron
Brian Barrett wrote:
> Personally, I'd rather just not mark MPI completion until a local
completion callback from the BTL. But others don't like that idea, so
we came up with a way for back pressure from the BTL to say "it's not
on the wire yet". This is more complicated than just not mar
Decrease the latency is the main reason. If we delay the MPI
completion, then we always have to call opal_progress at least once in
order to allow the BTL to trigger the callback. In the current
implementation, we never call opal_progress on small messages, unless
there is some kind of reso
On Thu, 2007-11-08 at 13:38 +0100, Torje Henriksen wrote:
> Hi,
>
> I have a question that I shouldn't need to ask, but I'm
> kind of lost in the code.
>
> The btl sm component is using the circular buffers to write and read
> fragments (sending and receiving).
>
> In the write_to_head and rea
The real memory copy happen in the convertor, more specifically in the
ompi_convertor_pack for the sender and in the ompi_convertor_unpack
for the receiver. In fact, none of the BTL directly call memcpy, all
memory movements are done via the convertor.
george.
On Nov 8, 2007, at 7:38 AM,
The alias option you presented does not work. I think we do some weird
things to find the absolute path for ssh, instead of just issuing the
command.
I would spend some time fixing this, but I don't want to do it wrong. We
could quote all the param values, and change the parser to remove the
Might I suggest:
https://svn.open-mpi.org/trac/ompi/ticket/1073
It deals with some of these issues and explains the boundaries of the
problem. As for what a string param can contain, I have no opinion. I only
note that it must handle special characters such as ';', '/', etc. that are
typically fo
Hi Gleb,
Gleb Natapov wrote:
In the case of TCP, kernel is kind enough to progress message for you,
but only if there was enough space in a kernel internal buffers. If there
was no place there, TCP BTL will also buffer messages in userspace and
will, eventually, have the same problem.
Occasion
On Thu, Nov 08, 2007 at 08:02:09AM -0500, Jeff Squyres wrote:
> >> All ROMIO patches *must* be coordinated with the ROMIO maintainers.
> > Upstream? That's the upstream patch.
> That was extracted from ROMIO itself? Which release?
>From Jiri:
The patch was extracted from a ROMIO sources that c
19 matches
Mail list logo
