Ouyang's Blog

Concepts

• Runner is an application that works with GitLab CI/CD to run jobs in a pipline.
• Runner can run multiple jobs and use multiple tokens with multiple servers.
• An executor determines the environment each job runs in.
• Jobs will be executed by executor in different platforms: Local, Docker, Docker with SSH, remote ssh server
• When you install GitLab Runner in a Docker container and choose the Docker executor to run your jobs, it’s sometimes referred to as a “Docker-in-Docker” configuration.
• Specify the name of the runner or its tags in your .gitlab-ci.yml file. Then, when you commit to your repository, the pipeline runs, and the runner’s executor processes the commands.

Docker in Docker configuration

Run GitLab Runner in a container

• You could use system volume mounts to start the Runner container

  1 2 3 4

  docker run -d --name gitlab-runner --restart always \ -v /srv/gitlab-runner/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:latest

  note: On macOS, use /Users/Shared instead of /srv .

SELinux

• Security-Enhanced Linux (SELinux) is a security architecture for Linux® systems that allows administrators to have more control over who can access the system.
• With Discretionary access control (DAC), files and processes have owners. You can have the user own a file, a group own a file, or other, which can be anyone else. Users have the ability to change permissions on their own files. The root user has full access control with a DAC system. If you have root access, then you can access any other user’s files or do whatever you want on the system.
• But on mandatory access control (MAC) systems like SELinux, there is administratively set policy around access. Even if the DAC settings on your home directory are changed, an SELinux policy in place to prevent another user or process from accessing the directory will keep the system safe.
• Traditionally, Linux and UNIX systems have used DAC. SELinux is an example of a MAC system for Linux.
  Read more »

Tensorflow Op Register

• Firstly, Mutable Hashtable should be registered as an TensorFlow Op.

• This Op will output a table_handle

  1 2 3 4 5 6 7 8 9 10 11 12 13

  REGISTER_OP("CUDAMutableHashTableV2") .Output("table_handle: resource") .Attr("container: string = ''") .Attr("shared_name: string = ''") .Attr("use_node_name_sharing: bool = false") .Attr("total_buckets: int = 131072") // 2^17 .Attr("key_dtype: type") .Attr("value_dtype: type") .SetIsStateful() .SetShapeFn([](InferenceContext* c) { return MutableHashTableShape(c, /*key=*/c->Scalar(), /*value=*/c->Scalar()); });

• According to TensorFlow CPU HashTable’s style, the following HashTable operations could be registered:

  • LookupTableFind
  • LookupTableInsert
  • LookupTableSize
  • LookupTableExport

• Those operations should take table_handle as the first input.

Introduction

• HugeCTR is a GPU-accelerated training framework for CTR estimation. It support model-parallel and data-parallel scaling.
• It explicitly prevents users from developing their model in a way that isn’t optimal, constraining to optimal layer width and memory sizes in order to achieve significant performance benefits.
  Read more »

Node/Graph related classes in tensorflow/core/framework

• NodeDef: located in node_def.proto

  • name: unique in a single graph
  • op name: start with ‘_’ for internal use
  • inputs: record the inputs of the node in the form of a string from which outputs of the node, the format is src_node: src_output
  • Device: request device of this node, optional, attr, etc

• NodeDefBuilder: located in node_def_builder.h

  • This class will build a NodeDef based on OpDef
  • NodeDef will record the input of this node from other nodes
    Read more »