Opened 7 years ago

Last modified 4 years ago

#1087 new bug

polling in Iprobe

Reported by: buntinas Owned by:
Priority: minor Milestone: future
Component: mpich Keywords:
Cc:

Description (last modified by balaji)

Calling nemesis nonblocking progress, will not process all messages that may be waiting in the shared memory queue (and fboxes). The progress engine checks the only queue once and processes the first message on the queue. Similarly, it will start checking each fbox but will stop at the first message it finds.

This can lead to performance issues when using a netmod and shared memory for apps that poll on Iprobe. Each call to Iprobe will cause the netmod to poll the network, which may be a system call. If the message being probed for is on the shared memory queue behind other packets, it may take several Iprobes, and therefore system calls, to match the expected message.

This ticket is a reminder for us to look at restructuring the progress engine to receive multiple shared memory messages per nonblocking progress call. Care must be taken to avoid livelock where a process that is constantly sending messages would cause another process to block indefinitely in an Iprobe.

Change History (5)

comment:1 Changed 7 years ago by buntinas

  • Milestone changed from mpich2-1.3.2 to mpich2-1.4

comment:2 Changed 7 years ago by balaji

  • Milestone changed from mpich2-1.4 to mpich2-1.5

comment:3 Changed 5 years ago by buntinas

  • Milestone changed from mpich2-1.5 to mpich-3.0

comment:4 Changed 5 years ago by balaji

  • Milestone changed from mpich-3.0 to mpich-3.0.1

comment:5 Changed 4 years ago by balaji

  • Description modified (diff)
  • Milestone changed from mpich-3.1 to future
  • Owner buntinas deleted
Note: See TracTickets for help on using tickets.