Embodiments generally relate to a virtual heterogeneous channel for message passing. Processes typically communicate through internode or intranode messages. There are many different types of standards that have been formed to attempt to simplify the communication of messages between processes. One such standard is the message passing interface (called “MPI”). MPI: A Message-Passing Interface Standard, Version 2.1, Message Passing Interface Forum, Jun. 23, 2008. MPI is essentially a standard library of routines that may be called from programming languages, such as FORTRAN and C. MPI is portable and typically fast due to optimization of the platform on which it is run.
In accordance with embodiments of the invention described herein two processes communicate messages with each other using a virtual heterogeneous channel. The virtual heterogeneous channel provides two paths for routing the protocol and user data that is associated with the messages: a first channel for routing all of the protocol data and some of the user data; and a second channel for routing the rest of the user data. As described below, in some embodiments of the invention, the selection of the channel for communicating the user data may be based on the size of the message or some other criteria. The virtual heterogeneous channel may be used for intranode communication or internode communication, depending on the particular embodiment of the invention.
As a more specific example,
For larger messages, however, the shared memory channel may be relatively inefficient for purposes of communicating user data, and as a result, the processes 22 and 28, in accordance with embodiments of the invention described herein, use a technique that is better suited for these larger messages. More specifically, a higher bandwidth channel for larger message sizes is used for purposes of communicating the user data for large messages. In accordance with some embodiments of the invention, a Direct Access Programming Library (DAPL) channel may be used to communicate larger messages. The DAPL establishes an interface to DAPL transports, or providers. An example is the Direct Ethernet Transport (DET).
Other architectures are within the scope of the appended claims. For example, in some embodiments of the invention, InfiniBand Architecture with RDMA capabilities may be used. The InfiniBand Architecture Specification Release 1.2 (October 2004) is available from the InfiniBand Trade Association at www.infinibandta.org. The DAPL channel has an initial large overhead that is attributable to setting up the user data transfer, such as the overhead associated with programming the RDMA adaptor with the destination address of the user data. However, after the initial setup, a data transfer through the DAPL channel may have significantly less latency than its shared memory channel counterpart.
More particularly, using the DAPL channel, one process 22, 28 may transfer the user data of a message to the other process 22, 28 using zero copy operations in which data is copied directly into a memory 24, 30 that is associated with the process 22, 28. The need to copy data between application memory buffers associated with the processes 22, 28 is eliminated, as the DAPL channel may reduce the demand on the host central processing unit(s) (CPU(s)) because the CPU(s) may not be involved in the DAPL channel transfer.
Due to the above-described latency characteristics of the DAPL and shared memory channels, in accordance with embodiments of the invention described herein, for smaller messages, the user data is communicated through the shared memory channel and for larger messages, the user data is communicated through the DAPL channel. It is noted that because the shared memory channel communicates all message protocol data (regardless of message size), ordering of the messages is preserved.
Referring to
In accordance with some embodiments of the invention, the above-described virtual heterogeneous channel may be created by a process using a technique 150 that is depicted in
A process may transmit a message using the virtual heterogeneous channel pursuant to a technique 200 that is depicted in
Assuming a virtual heterogeneous channel exists, the process determines (diamond 214) whether a size that is associated with the message is greater than a particular value of a threshold. If so, then the process designates the user data of the message to be sent through the DAPL channel and the protocol data to be sent through the shared memory channel, pursuant to block 220. Otherwise, if the message size is less than the value of the threshold, the process designates the entire message to be sent through the shared memory channel, pursuant to block 224. Subsequently, the message is sent via the virtual heterogeneous channel, pursuant to block 230.
For purposes of receiving a message via the virtual heterogeneous channel, a process may use a technique 250, which is depicted in
Otherwise, if a virtual heterogeneous channel exists, then the process determines (diamond 262) whether the message received is through the shared memory channel only. If so, then the process initializes (block 270) the reception of the user data through the shared memory channel. It is noted that the protocol data is always transmitted through the shared memory channel. If the message is not received only through the shared memory channel, then the process initializes (block 268) the reception of the user data through the DAPL channel. After the reception of the message has been initialized, the process receives the message through the heterogeneous channel, pursuant to block 272.
Other embodiments are within the scope of the appended claims. For example, in accordance with other embodiments of the invention, the selection of the channel for communicating the user data may be based on criteria other than message size. More specifically, every n-th message may be sent through the DAPL channel for purposes of balancing the load between the DAPL and shared memory channels.
Embodiments further allow a MPI library to work efficiently in event driven (wait) mode during simultaneous data transfers through shared memory inside a node, and through other communication fabrics between nodes like Ethernet and InfiniBand. This minimizes processor cycles spent on memory and device polling, and thus increases availability to user data processing, and drives down dissipated heat.
By introducing a wait (or event driven) mode into a MPI library, substantially reduced CPU overhead associated with polling can be realized, and nearly uniform performance for unifabric and multifabric communication configurations may be obtained. One embodiment may work as follows. During MPI process initialization, a small shared memory segment is created. This segment contains a synchronization block for every process, identified by the process rank. The information about the location of this shared memory segment is distributed across the MPI job using out-of-band communication such as a process management interface (PMI). Each block may include, among other information, the following fields: a “wait” flag which is set to TRUE when the process involved enters the wait state; a “wake_up” message counter that counts the number of messages that has been sent to other processes but not yet received by them; a “connection” counter that contains the number of connections initiated by other processes to the process involved; and pointer to a mutex that is used to synchronize processes during modification or inquiry of the synchronization block contents.
During connection establishment, heterogeneous channels may be employed, as described in
In various embodiments, the wait mode is implemented using only intranode heterogeneous channels, like SHM-DAPL for shared memory and DAPL transfers, or SHM-SOCK for shared memory and sockets. If one process initializes a shared memory connection to another intranode process, it increments the counter of the initialized connections, and starts sending a wake-up message (e.g., blocks 320 and 330 of
Specifically, as shown in
Accordingly, method 300 may next initiate sending of a wakeup message to process I (block 330). This triggers a progress engine, which is called at block 335. Thus a SHM connection with this process may be established. It may next be determined if the SHM connection is established with process J (diamond 340) and if so the variable VCConnectionsConfiguration for this connection may be set to SHM_BIT_MASK (block 345). It may be determined whether the DAPL connection operation has been completed (diamond 350). If so, the variable VCConnectionsConfiguration for this connection may be set to DAPL_BIT_MASK (block 355). Then it may be determined whether the variable IntranodeDeviceConfiguration is equal to VCConnectionsConfiguration value (diamond 360). If so, control passes to diamond 365.
At diamond 365 it may be determined whether the established connection was initiated by the current process. If so, control passes to block 380, below. Otherwise a counter of initiated connections in the synchronization block for process J may be decremented (block 370). Finally, method 300 concludes with the completion of the creation of a heterogeneous VC between current and J processes (block 380). In this way, creation of an intranode heterogeneous VC between two processes can be performed in RDSSM wait mode.
Referring now to
Thus as shown in
Referring now to
Thus as shown in
In various embodiments, the wake-up messages are sent as internal control messages, for example, through the DAPL or sockets part of the heterogeneous channel. The transfer of such messages, like of any other message, can be delayed if there are no free buffers to accommodate them. In this case, a special flag is raised in the respective VC structure, and the wake-up message is sent after the current message. The receiving process decrements the wake-up counter in its synchronization block.
Referring now to
Otherwise, control passes to block 620 where DAPL read and write progress may be made. Next it may be determined whether any DAPL read/write operations are completed (diamond 630). If so, the progress engine may conclude (block 685). Otherwise, connections over shared memory may be checked (block 635). It may then be determined whether there are any completed SHM connection operations at diamond 640. If so, the progress engine for the wait mode may conclude. Otherwise, connections over DAPL may be checked (block 650). It may then be determined whether there are any completed DAPL connection operations at diamond 660.
Next, at block 665 a spin count variable (SpinCount) may be decremented and at diamond 670 it may be determined whether the spin count is less than or equal to zero. If not, control passes back to block 610 discussed above. If the spin count is equal to zero, control passes to block 675, where the internal Wait( ) function may be called, and the spin count is reinitialized (block 680). Then control may pass back to block 610 for making further shared memory read/write progress. While shown with this particular implementation in the embodiment of
As shown in
Referring now to
Referring still to
Thus in the internal function Wait( ), the wait mode is entered only after a series of conditions have been met, as shown in
Note that if all above conditions misfire, the process calls the respective FabricXxxxWait( ) function (block 750) for the fabric used for internode data transfer (e.g., the DAPL connection). In this case the waiting process will be activated, either due to the receipt of a message from another node, or due to receipt of the wake-up message from another process on the same node.
Embodiments thus provide a unified approach to the wait mode implementation based on virtual channels. This approach reduces waiting on all active fabrics to waiting on only one of them, and merges the advantages of polling and event driven methods. Note there is no reliance on the presence of helper threads or system provided file descriptor capabilities for all the fabrics involved. This allows a MPI to use fabrics that do not have those capabilities, and to do without extra threads that tend to slow down processing.
Embodiments may further allow an MPI library to work more efficiently in event driven (wait) mode using DAPL providers that supports RDMA technologies. Specifically, the number of data transfer operations (DTOs) required for passing messages from one remote process to another can be reduced by writing data into memory of a remote process with immediate data (referred to herein as a RDMA write with immediate data) and therefore improves the performance of message passing in event driven mode.
The problem of waiting for DTO completions of a RDMA write operation from a remote process is raised during implementation of wait mode. The event for DTO completion of a RDMA from a write is delivered onto the event dispatcher (EVD) of the process that posted the operation. The process receiving data, to detect the completion of data transfer should poll memory and check head and tail flags of the incoming message. However, this method can not be applied in wait mode because of intensive processor usage. While this issue can be solved by sending special “wake-up” messages using DAPL send (on sending side) and recv (on receiving side) DTO operations, an increased number of DTO operations involved to transfer the data affects performance, and is especially sensitive at passing short size messages.
Thus in some embodiments a single “RDMA Write with immediate data” operation may be used instead of two RDMA Write and send operations. Specifically, an EVD for handling the completions of “recv” DTO is created by a function call dat_evd_create( ), at the initialization stage together with other DAPL objects.
Then when there is a necessity to transfer the data, a sending process initiates the operation “RDMA Write with immediate data” by calling the function “dat_ib_post_rdma_write_immed_data( ).” This function allows the process to send immediate data together with user data sent by RDMA write. The immediate data are delivered to the remote process inside of the event structure for a “recv” DTO completion event and effectively acts as the control message carrying part of the virtual channel. In one embodiment, a 4 byte size immediate data may be used to specify the type of operation to the receiving process. Then the receiving process handles the incoming data depending on this type. For instance, the type of operation can specify one of following cases: eager data sent through internal pre-registered buffers; a credit update message that contains information about a possibility to re-use some pre-registered buffers; or a rendezvous acknowledge message (ACK) that notifies the remote process about completion of a rendezvous RDMA operation.
Referring now to
Referring still to
As further shown in
To handle a received message, a receiving process posts in advance several “recv” operations calling a dat_ep_post_recv( ) function to get the immediate data from the sending process. The completion of the “recv” operation guarantees that the main useful data transferred by RDMA write has been delivered. In order to detect the completion of “recv” operations, the process calls either dat_evd_dequeu( ) to inquire a receive EVD or dat_evd_wait( ) to wait for a DTO completion event without processor utilization.
Referring now to
Control passes then to diamond 915 where it may be determined whether there is any data in internal RDMA buffers. If so, the data may be copied to a user buffer (block 920). Next it may be determined whether the receive is completed (diamond 930). If so, the method may conclude, otherwise control passes back to diamond 915.
If there is no data in the internal RDMA buffers, next a connection EVD may be inquired (block 935), and it may be determined if there are any connection events (diamond 940). If so, the connection event may be handled (block 950). Then it may be determined whether a connection is established (diamond 955). If so, the function calls for hosting the “recv” operations may be called (block 960). In either event, control passes back again to diamond 915.
Referring still to
Referring still to
Note that when a “recv” DTO completion event is received, the immediate data will be retrieved, the type of RDMA Write operation will be analyzed so that the transferred data will be handled in the appropriate way, as shown in
If dynamic connection (on demand) mode is used, an additional EVD may be created to handle the connection events. In this case a DAPL CNO object is used to consolidate several event dispatchers and is allowed to wait (calling dat_cno_wait) for the events related to both connection establishment and DTO completions. Thus using such an embodiment, the latencies of short-size messages in wait mode of, e.g., an InfiniBand RDMA path can be reduced.
Embodiments can be implemented in different system types. Shown in
For simplicity and ease of understanding, the example two node system of
Each application 1115 may be written and linked to a MPI implementation different than that of an associated MPI library 1130 (generally). To enable easy transition to the corresponding native MPI 1130, an application binary interface (ABI) wrapper 11201-1120n (generically wrapper 1130) written to the same MPI implementation as application 1115 may intercept MPI calls made by the process 1115 to library 11301-1130n (generically library 1130) of
Embodiments may be implemented in code and may be stored on a storage medium having stored thereon instructions which can be used to program a system to perform the instructions. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.
While the invention has been disclosed with respect to a limited number of embodiments, those skilled in the art, having the benefit of this disclosure, will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of the invention.
This application is a continuation of U.S. patent application Ser. No. 12/290,615, filed Oct. 31, 2008, now U.S. Pat. No. 7,949,815 which is a continuation-in-part of U.S. application Ser. No. 11/528,201, filed Sep. 27, 2006, now abandoned the content of which is hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
4395757 | Bienvenu et al. | Jul 1983 | A |
4862350 | Orr et al. | Aug 1989 | A |
5214759 | Yamaoka et al. | May 1993 | A |
5224215 | Disbrow | Jun 1993 | A |
5333269 | Calvignac et al. | Jul 1994 | A |
5357612 | Alaiwan | Oct 1994 | A |
5434975 | Allen | Jul 1995 | A |
5463629 | Ko | Oct 1995 | A |
5502840 | Barton | Mar 1996 | A |
5606666 | Grant et al. | Feb 1997 | A |
5617537 | Yamada et al. | Apr 1997 | A |
5625795 | Sakakura et al. | Apr 1997 | A |
5706516 | Chang et al. | Jan 1998 | A |
5815167 | Muthal et al. | Sep 1998 | A |
5860126 | Mittal | Jan 1999 | A |
5911051 | Carson et al. | Jun 1999 | A |
6018763 | Hughes et al. | Jan 2000 | A |
6038592 | Verplanken et al. | Mar 2000 | A |
6075787 | Bobeck et al. | Jun 2000 | A |
6182168 | Guthrie | Jan 2001 | B1 |
6243793 | Aucsmith et al. | Jun 2001 | B1 |
6314501 | Gulick et al. | Nov 2001 | B1 |
6314563 | Agesen et al. | Nov 2001 | B1 |
6385658 | Harter, et al. | May 2002 | B2 |
6467011 | Scardamalia et al. | Oct 2002 | B2 |
6510478 | Jeffords et al. | Jan 2003 | B1 |
6601089 | Sistare et al. | Jul 2003 | B1 |
6665601 | Nielson | Dec 2003 | B1 |
6704765 | Chang et al. | Mar 2004 | B1 |
6718398 | Dontje et al. | Apr 2004 | B1 |
6752836 | Copeland et al. | Jun 2004 | B1 |
6779090 | McKenney et al. | Aug 2004 | B2 |
6799317 | Heywood et al. | Sep 2004 | B1 |
6810470 | Wiseman et al. | Oct 2004 | B1 |
6886031 | Venkatsubramanian et al. | Apr 2005 | B2 |
6920485 | Russell | Jul 2005 | B2 |
6978143 | Vialen | Dec 2005 | B1 |
7032023 | Barrett et al. | Apr 2006 | B1 |
7124211 | Dickson et al. | Oct 2006 | B2 |
7142650 | Kult et al. | Nov 2006 | B1 |
7216349 | Chen et al. | May 2007 | B2 |
7231638 | Blackmore et al. | Jun 2007 | B2 |
7287127 | Anand et al. | Oct 2007 | B2 |
7313794 | Ansari | Dec 2007 | B1 |
7373438 | DeBergalis et al. | May 2008 | B1 |
7383368 | Schopp | Jun 2008 | B2 |
7472208 | Rothman et al. | Dec 2008 | B2 |
7886300 | Long et al. | Feb 2011 | B1 |
7949815 | Supalov et al. | May 2011 | B2 |
7996848 | McClure et al. | Aug 2011 | B1 |
20020013822 | West | Jan 2002 | A1 |
20020087769 | McKenney et al. | Jul 2002 | A1 |
20030023776 | Kolinummi et al. | Jan 2003 | A1 |
20030070021 | Joy et al. | Apr 2003 | A1 |
20030220987 | Pearson | Nov 2003 | A1 |
20050021658 | Nicholas et al. | Jan 2005 | A1 |
20050080963 | Schopp | Apr 2005 | A1 |
20060075119 | Hussain et al. | Apr 2006 | A1 |
20060136640 | Tuan | Jun 2006 | A1 |
20060167825 | Sayal | Jul 2006 | A1 |
20060184672 | Lauer et al. | Aug 2006 | A1 |
20060242327 | Knight et al. | Oct 2006 | A1 |
20060259572 | Brown | Nov 2006 | A1 |
20070097952 | Truschin | May 2007 | A1 |
20070124728 | Rosenbluth et al. | May 2007 | A1 |
20070293984 | Lin et al. | Dec 2007 | A1 |
20100042788 | Lee et al. | Feb 2010 | A1 |
20100191823 | Archer et al. | Jul 2010 | A1 |
20110289180 | Sonnier et al. | Nov 2011 | A1 |
Number | Date | Country |
---|---|---|
628914 | Dec 1994 | EP |
629955 | Dec 1994 | EP |
04236647 | Aug 1992 | JP |
04295952 | Oct 1992 | JP |
08016540 | Jan 1996 | JP |
11085518 | Mar 1999 | JP |
11120157 | Apr 1999 | JP |
2000339181 | Dec 2000 | JP |
2006048249 | Feb 2006 | JP |
Number | Date | Country | |
---|---|---|---|
20110185100 A1 | Jul 2011 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 12290615 | Oct 2008 | US |
Child | 13082649 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11528201 | Sep 2006 | US |
Child | 12290615 | US |