rajesh-s

Tested on Graviton2, ARM64, Ubuntu 22.04

git clone https://github.com/torvalds/linux.git # I did not have to match my kernel version to the source tree
cd tools/perf
sudo apt install make gcc flex bison pkg-config libzstd1 libdwarf-dev libdw-dev binutils-dev libcap-dev libelf-dev libnuma-dev python3 python3-dev python-setuptools libssl-dev libunwind-dev libdwarf-dev zlib1g-dev liblzma-dev libaio-dev libtraceevent-dev debuginfod libpfm4-dev libslang2-dev systemtap-sdt-dev libperl-dev binutils-dev libbabeltrace-dev libiberty-dev libzstd-dev python-dev-is-python3 libssl-dev python3-dev libpython3.10-dev libcapstone-dev
make # Ensure that all flags are turned on as necessary

rajesh-s

Add the following to a file grub-menu.sh to get the index number of the grub entry such as GRUB_DEFAULT="1>6" in /etc/default/grub and then run sudo update-grub

Source

#!/bin/bash

# NAME: grub-menu.sh
# PATH: $HOME/bin
# DESC: Written for AU Q&A: https://askubuntu.com/q/1019213/307523

rajesh-s

Reference to get around

Screen

screen -S <session_name>
screen -ls
screen -r <attach_to_session>
Ctrl + A and then D to detach
screen -X -S <screen session> quit

rajesh-s

Delving into the why's of AXI

**Note: In all below, slave can also mean interconnect

• Do we really need back-pressure?
  • Yes, you absolutely need backpressure. What happens when two masters want to access the same slave? One has to be blocked for some period of time. Some slaves may only be able to handle a limited number of concurrent operations and take some time to produce a result. As such, backpressure is required.
  • B and R channel backpressure is required in the case of contention towards the master. If a master makes burst read requests against two different slaves, one of them is gonna have to wait.
    • Shouldn't a master be prepared to receive the responses for any requests it issues from the moment it makes the request? Aside from the clock crossing issue someone else brought up, and the interconnect issue at the heart of the use of IDs, why should an AXI master ever stall R or B channels?
• The master should be prepared, but it only has one R and one B input, so it can't re

rajesh-s

// Sample file using the Google C++ coding standard.
//
// http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
//
// General rules:
//   - Indents are two spaces. No tabs should be used anywhere.
//   - Each line must be at most 80 characters long.
//   - Comments can be // or /* but // is most commonly used.
//   - File names should be lower_case.c or lower-case.c
//

rajesh-s

alias res='mkdir results_$(date '+%Y%m%d')'
alias crm='condor_rm'
alias chk='watch -n 1 condor_q --nobatch'
alias why='condor_q -hold'

rajesh-s

rocprof -i input.xml --timestamp on --basenames on --stats

input.xml

List of metrics

<metric name=TCC_HIT[0],TCC_HIT[1],TCC_HIT[2],TCC_HIT[3],TCC_HIT[4],TCC_HIT[5],TCC_HIT[6],TCC_HIT[7],TCC_HIT[8],TCC_HIT[9],TCC_HIT[10],TCC_HIT[11],TCC_HIT[12],TCC_HIT[13],TCC_HIT[14],TCC_HIT[15],TCC_MISS[0],TCC_MISS[1],TCC_MISS[2],TCC_MISS[3],TCC_MISS[4],TCC_MISS[5],TCC_MISS[6],TCC_MISS[7],TCC_MISS[8],TCC_MISS[9],TCC_MISS[10],TCC_MISS[11],TCC_MISS[12],TCC_MISS[13],TCC_MISS[14],TCC_MISS[15],TCC_EA_RDREQ[3],TCC_EA_RDREQ[4],TCC_EA_RDREQ[5],TCC_EA_RDREQ[6],TCC_EA_RDREQ[7],TCC_EA_RDREQ[8],TCC_EA_RDREQ[9],TCC_EA_RDREQ[10],TCC_EA_RDREQ[11],TCC_EA_RDREQ[12],TCC_EA_RDREQ[13],TCC_EA_RDREQ[14],TCC_EA_RDREQ[15],TCC_EA_WRREQ[0],TCC_EA_WRREQ[1],TCC_EA_WRREQ[2],TCC_EA_WRREQ[3],TCC_EA_WRREQ[4],TCC_EA_WRREQ[5],TCC_EA_WRREQ[6],TCC_EA_WRREQ[7],TCC_EA_WRREQ[8],TCC_EA_WRREQ[9],TCC_EA_WRREQ[10],TCC_EA_WRREQ[11],TCC_EA_WRREQ[12],TCC_EA_WRREQ[13],TCC_EA_WRREQ[14],TCC_EA_WRREQ[15] >

rajesh-s

docker run -w /root -it accelsim/ubuntu-18.04_cuda-11 /bin/bash
git clone -b release-accelwattch https://github.com/accel-sim/accel-sim-framework/
cd /usr/local/cuda-11.0/
ln -s cuda-11.0 cuda-11
cd -
cd accel-sim-framework
export PATH=$CUDA_INSTALL_PATH/bin:$PATH
git clone https://github.com/accel-sim/gpu-app-collection  
source ./gpu-app-collection/src/setup_environment 

rajesh-s

# Usage:
# Copy this file with the same name "note-link-janitor-gh-action-workflow.yml" to the <repo>/.github/workflows/ folder
# I keep all my *.md files in SRC and run janitor only on that folder. If you keep it in the root of repository or any other folder, feel free to update it on line 37 of this file
# The workflow gets triggered every time you push to your repository
name: note-link-janitor-gh-action-workflow

# Run this workflow every time a new commit pushed to your repository
on: push

jobs:

rajesh-s

$ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu1804/x86_64/3bf863cc.pub
$ sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/machine-learning/repos/ubuntu1804/x86_64/7fa2af80.pub