Hama
  1. Hama
  2. HAMA-546

Add access to remote memory (BSP_GET,BSP_PUT)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: bsp core
    • Labels:
      None

      Description

      bsp_get and bsp_put are integral parts of the BSP computing model.
      They are defined as follows:

      bsp_get [1]

      The bsp_get(3) and bsp_hpget(3) operations reach into the
      local memory of another process and copy previously
      registered remote data held there into a data structure in
      the local memory of the process that initiated them.

      bsp_put [2]

      The aim of bsp_put(3) and bsp_hpput(3) is to provide an
      operation akin memcpy(3C) available in the Unix <string.h>
      library. Both operations copy a specified number of bytes,
      from a byte addressed data structure in the local memory of
      one process into contiguous memory locations in the local
      memory of another process. The distinguishing factor between
      these operations is provided by the buffering choice.

      A very simple implementation can be based on a HashMap on every peer which can be obtained via RPC.
      In this case we need to extend the MessageManager to be able to do off-the-band communication.
      It would be great to extract a common interface which can be inter-operable with other caching tools like DirectMemory or EHCache.

      [1] http://www.bsp-worldwide.org/implmnts/oxtool/man/bsp_get.3.html
      [2] http://www.bsp-worldwide.org/implmnts/oxtool/man/bsp_put.3.html

      1. HAMA-546_1.patch
        12 kB
        Thomas Jungblut

        Issue Links

          Activity

          Hide
          praveen sripati added a comment -

          There is a section on DRMA (Direct Remote Memory Access) in (1) - page 8. Not sure if Hama tries to mimic API similar to BSPLib, but it would make Hama adoption smooth.

          (1) - http://cloudscale.com/images/bsp/BSPLIBPC.PDF

          Show
          praveen sripati added a comment - There is a section on DRMA (Direct Remote Memory Access) in (1) - page 8. Not sure if Hama tries to mimic API similar to BSPLib, but it would make Hama adoption smooth. (1) - http://cloudscale.com/images/bsp/BSPLIBPC.PDF
          Hide
          praveen sripati added a comment - - edited

          Can we use zero copy transfer as mentioned in this IBM DW article? Would be useful for transferring large amounts of data efficiently across nodes.

          http://www.ibm.com/developerworks/library/j-zerocopy/

          Show
          praveen sripati added a comment - - edited Can we use zero copy transfer as mentioned in this IBM DW article? Would be useful for transferring large amounts of data efficiently across nodes. http://www.ibm.com/developerworks/library/j-zerocopy/
          Hide
          Thomas Jungblut added a comment -

          Sorry Praveen, I'm not going to write my own RPC library just to get 10% less latency.
          We use the MessageManager implementation defined, Hadoop/AVRO+Protobuf RPC.

          Show
          Thomas Jungblut added a comment - Sorry Praveen, I'm not going to write my own RPC library just to get 10% less latency. We use the MessageManager implementation defined, Hadoop/AVRO+Protobuf RPC.
          Hide
          Thomas Jungblut added a comment -

          First API scratch of how it should look like.

          I think we should have multiple "CacheServices" each with generic key and value, each cache service is identifiable via a String name.

          Every service instantiated will be managed by the CacheHandler (maybe we can rename to CacheManager to be consistent with sync and messaging).

          Then there are concurrent caches and normal caches.

          The first patch includes just a rough implementation of normal caches with a map and a queue.

          Currently I am not sure whether we should put the CacheHandler into the Peer or into the MessageManager, but I think the Peer should be the best decision.

          As an example of put and get we should add the realtime usage in our wiki.

          Show
          Thomas Jungblut added a comment - First API scratch of how it should look like. I think we should have multiple "CacheServices" each with generic key and value, each cache service is identifiable via a String name. Every service instantiated will be managed by the CacheHandler (maybe we can rename to CacheManager to be consistent with sync and messaging). Then there are concurrent caches and normal caches. The first patch includes just a rough implementation of normal caches with a map and a queue. Currently I am not sure whether we should put the CacheHandler into the Peer or into the MessageManager, but I think the Peer should be the best decision. As an example of put and get we should add the realtime usage in our wiki.
          Hide
          Suraj Menon added a comment -

          Checked the patch. I have following design questions/points to consider.
          Should the key for retrieval be a function of both the userKey and superstep count in which the value is computed?
          Which implies should we support retrieval only for values in the previous superstep or should we support values for all the supersteps?

          Show
          Suraj Menon added a comment - Checked the patch. I have following design questions/points to consider. Should the key for retrieval be a function of both the userKey and superstep count in which the value is computed? Which implies should we support retrieval only for values in the previous superstep or should we support values for all the supersteps?
          Hide
          Thomas Jungblut added a comment -

          Yeah integration is key

          Should the key for retrieval be a function of both the userKey and superstep count in which the value is computed?

          I think we should provide another implementation like a SuperstepMap where you can store things like this thoughout superstep numbers.

          Which implies should we support retrieval only for values in the previous superstep or should we support values for all the supersteps?

          Both is possible, because you can have many caches, all doing different implementation dependend things.
          We should just try to make this as simple as possible.

          Show
          Thomas Jungblut added a comment - Yeah integration is key Should the key for retrieval be a function of both the userKey and superstep count in which the value is computed? I think we should provide another implementation like a SuperstepMap where you can store things like this thoughout superstep numbers. Which implies should we support retrieval only for values in the previous superstep or should we support values for all the supersteps? Both is possible, because you can have many caches, all doing different implementation dependend things. We should just try to make this as simple as possible.

            People

            • Assignee:
              Unassigned
              Reporter:
              Thomas Jungblut
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development