SlideShare a Scribd company logo
1 of 20
DPKG Caching Framework
- Kalimuthu Velappan (Broadcom)
- Greg Paussa (Broadcom)
Introduction
• Key feature of SONiC build
• Plug-and-play of a module
• Inter-module dependency through .deb packages
• What’s missing in SONiC?
• No incremental build support ( Any change in source will trigger rebuild from scatch)
• Long time to build
• DPKG caching framework provides an infrastructure to cache the SONiC module/target/docker
.deb files into a local cache
• Module/Target Dependency file tracking
• Inter-module dependency
• Environment variable changes
• Two-level caching support
• Support for true incremental build
• Overall build time reduction
SONiC Build Framework
• Each module compiles the
source code and generates the
.deb package
• Main .deb package and zero or
more derived packages
• Clean compilation( no incremental
support)
• From the .deb packages
• sonic-<image>.bin
• docker-<image(s)>.gz
SONiC Build Module(s)
(e.g. linux, libnl ,etc.)
Compile and build .deb
Build Artifacts
target/debs/module(s).deb
Docker Images
target/docker-images(s).gz
SONiC Image
target/sonic-<vendor.bin>
SONiC Build Organization
1. SONiC repo
• Source code is part of repo
• Build and generate the .deb package
2. Non-SONiC repo
• Download the source file
• Apply the patch files
• Build and generate the .deb package
3. Non-source files
• Download the .deb file directly from web or remote server
SONiC DPKG Caching Framework
SONiC Build
Module(s)
(e.g. linux, libnl, etc.)
Compile and build .deb
Build Artifacts
target/debs/module(s).deb
Docker Images
target/docker-images(s).gz
SONiC Image
target/sonic-<vendor.bin>
Module(s) .deb Cache
Cache framework
Module(s) dependency files
Git Database Commands
• To get the SHA value of a file: hash-object
# git hash-object slave.mk some-new-file.txt
ef2de5371650c4460dea3ad3887a4d6d57cbc845
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
• To get all the files in a module: ls-files
# git ls-files -cms src/bash
100644 9395dcd541987faae588462a63d06c303b11cebe 0 src/bash/Makefile
100644 253475b21878b3373c21f9ec7ba6ad14c220cbdd 0 src/bash/patch/series
100644 2a19c9e70d3c38572f81a7c62cb722e5c80f939c 0 src/bash/patch/readline.patch
• To get the modified files in a module: status
# git status -s src/bash
M src/bash/Makefile
Dependency Tracking
Dependencies > Target deb
Common Dependencies
( rules/config , slave.mk, rules/functions )
ENV Flags
(SONIC_DEBUGGING_ON, SONIC_PROFILING_ON , etc.)
Load deb from cache
Not modified
Compile and build deb
Modifed
Dependency SHA
Module Dependencies
( Makefile, debian/rules, srcs, patch files, etc.)
DPKG Cache
Derived .deb(s)
Dependency Generation
• Use git ls-files command to get
the list of files for a module
• Add package specific
dependency files .mk, .dep, etc. <target> ( Eg: bash)
rules/<target>.dep
rules/<target>.mk
target/debs/stretch/<target>.deb
target/debs/stretch/<target>.deb .dep
target/debs/stretch/<target>.deb .dep.sha
Dependency Generation
BASH
src/bash/Makefile
src/bash/patch/series
src/bash/patch/readline.patch
rules/bash.mk
rules/bash.dep
target/debs/stretch/bash-4.3-14_amd64.deb.dep
9395dcd541987faae588462a63d06c303b11cebe src/bash/Makefile
253475b21878b3373c21f9ec7ba6ad14c220cbdd src/bash/patch/series
2a19c9e70d3c38572f81a7c62cb722e5c80f939c src/bash/patch/readline.patch
git ls-files src/bash
target/debs/stretch/bash-4.3-14_amd64.deb.dep.sha
target/debs/stretch/bash-4.3-14_amd64.deb
24 byte SHA
git hash-object target/debs/stretch/bash-4.3-14_amd64.deb.dep.sha
SONIC_DEBUG_ON=y
SONIC_PROFILE_ON=N
target/debs/stretch/bash-4.3-14_amd64.deb.flags
Dependencies (DEPENDS, RDEPENDS etc)
24 byte SHA
/cache/bash-4.3-14_amd64.deb-<24B sha>-<24B sha>.tgz
git hash-object <dep files>
Dependency File Generation
• rules/<target>.mk
• rules/<target>.dep
SPATH := $($(BASH)_SRC_PATH)
DEP_FILES := $(SONIC_COMMON_FILES_LIST) rules/bash.mk rules/bash.dep
DEP_FILES += $(SONIC_COMMON_BASE_FILES_LIST)
DEP_FILES += $(shell git ls-files $(SPATH))
$(BASH)_CACHE_MODE := GIT_CONTENT_SHA
$(BASH)_DEP_FLAGS := $(SONIC_COMMON_FLAGS_LIST)
$(BASH)_DEP_FILES := $(DEP_FILES)
rules/bash.dep
# Common Files
# rules/config, slave.mk,
rules/functions etc.
# Base Files
# sonic-slave*/Dockerfile*,
# Common Flags
# SONIC_DEBUGGING_ON, SONIC_PROFILING_ON
etc.
BASH_VERSION_FULL = 4.3-14
BASH = bash_$(BASH_VERSION_FULL)_amd64.deb
$(BASH)_SRC_PATH = $(SRC_PATH)/bash
SONIC_MAKE_DEBS += $(BASH)
rules/bash.mk
Cache File Tracking
The cache file is a compressed TAR ball of a module's target DEB file and its derived-target DEB files.
The cache filename is constructed as follows:
FORMAT:
<module deb filename>-<24 byte SHA hash>-<24 byte SHA hash>.tgz
Eg:
linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u3_all.deb-fa16f47c0b63fa16f47c0b63-fd21bb776fa16f47c0b6.tgz
<24-byte SHA value> - derived from the following:
DEPENDS, RDEPENDS, WHEEL_DEPENDS, PYTHON_DEBS, PYTHON_WHEELS
DBG_DEPENDS, DBG_IMAGE_PACKAGES, LOAD_DOCKERS
<24-byte SHA value> - derived from either of the following:
GIT_COMMIT_SHA - SHA value of the last git commit ID if it is a submodule
GIT_CONTENT_SHA - SHA value is generated from the content of the target dependency
Support for Environmental Flags
• Support for Environment flags
• SONIC_DEBUGGING_ON = y
• SONIC_PROFILING_ON = y
• Etc.
• Support for inter-module dependency changes
• If Module B depends on Module A, any changes to module A will:
• Skip cache loading for module A and B, and
• Rebuild modules A and B
Module Makefile
• Module Makefile/Makefile.am
• Must specify source files explicitly in Makefile
• SRCS = $(wildcard *.c)  Not OK
• SRCS = src1.c src2.c src3.c  OK
Cache Hierarchy
• Two-level cache hierarchy:
• Global Caching
• Committed changes
• Module files are not modified
• Cache location:
• Outside of sonic-buildimage folder
• Local Caching
• Local changes prior to commit (doesn’t change the global cache - Development)
• Module files are modified
• Dependent target(s) updated
• Cache location:
• sonic-buildimage/target/cache
Cache Disable
• Global
• rules/config file:
• SONIC_DPKG_CACHE_METHOD=none
• Build environment:
• make SONIC_DPKG_CACHE_METHOD=none
• Per-module
• rules/<target>.dep file:
• $(TARGET)_CACHE_MODE := none
• To force a rebuild
• Rebuild cache with latest changes:
• make SONIC_DPKG_CACHE_METHOD=rebuild
• Use when the source is modified outside the sonic ‘git repo’
Cache Location
• Can choose where to locate the DPKG cache:
• Local tmp storage
• /tmp/dpkg_cache
• Local disk storage
• /dpkg_cache
• NFS mount
• /mnt/dpkg_cache
• Cache size
• 3G (All the .debs)
• Incremental
Cache Cleanup
• Recently used cache files are updated with newer timestamp.
• The DPKG framework automatically touch the used cache files to current
timestamp.
• touch /<cache_path>/<cache_file>.tgz
• Least-recently-used cache file cleanup command:
• find <cache_path> -name “*.tgz” ! -mtime -7 –exec rm {} ;
• Where:
-mtime n => Files were modified within last n*24 hours .
-mtime -7 => means ( -7 * 24 ) => Files were modified within last 7 days
! -mtime -7 => Files were modified 7 days ago
Build Time Comparison
• Cached Build
• SSD / 48 Core
• BUILD_JOBS=48, MAKE_JOBS=48
• 8 Minutes
• SSD / 16 Core
• BUILD_JOBS=16, MAKE_JOBS=16
• 12 Minutes
• Fresh Build
• SSD / 48 Core
• BUILD_JOBS=48, MAKE_JOBS=48
• 55 Minutes
• SSD / 16 Core
• BUILD_JOBS=16, MAKE_JOBS=16
• 80 Minutes (1.20 )
Phase II
• The final target/<vendor>-sonic.bin image generation takes around 10
minutes.
• rootfs segregation
• DPKG package database migration
• Base rootfs (Cached)
• SONiC fs
• DPKG database fs
Thank You
Thanks to Greg Paussa(Broadcom) for the initial design of local caching for Linux kernel

More Related Content

Similar to DPKG caching framework-latest .pptx

Yocto: Training in English
Yocto: Training in EnglishYocto: Training in English
Yocto: Training in English
Otavio Salvador
 
git-and-bitbucket
git-and-bitbucketgit-and-bitbucket
git-and-bitbucket
azwildcat
 

Similar to DPKG caching framework-latest .pptx (20)

Build Automation of PHP Applications
Build Automation of PHP ApplicationsBuild Automation of PHP Applications
Build Automation of PHP Applications
 
Scaling Development Environments with Docker
Scaling Development Environments with DockerScaling Development Environments with Docker
Scaling Development Environments with Docker
 
Altoros Cloud Foundry Training: hands-on workshop for DevOps, Architects and ...
Altoros Cloud Foundry Training: hands-on workshop for DevOps, Architects and ...Altoros Cloud Foundry Training: hands-on workshop for DevOps, Architects and ...
Altoros Cloud Foundry Training: hands-on workshop for DevOps, Architects and ...
 
PostgreSQL and Linux Containers
PostgreSQL and Linux ContainersPostgreSQL and Linux Containers
PostgreSQL and Linux Containers
 
An introduction to maven gradle and sbt
An introduction to maven gradle and sbtAn introduction to maven gradle and sbt
An introduction to maven gradle and sbt
 
SenchaCon 2016: Develop, Test & Deploy with Docker - Jonas Schwabe
SenchaCon 2016: Develop, Test & Deploy with Docker - Jonas Schwabe SenchaCon 2016: Develop, Test & Deploy with Docker - Jonas Schwabe
SenchaCon 2016: Develop, Test & Deploy with Docker - Jonas Schwabe
 
Introduction to Docker
Introduction to DockerIntroduction to Docker
Introduction to Docker
 
Yocto: Training in English
Yocto: Training in EnglishYocto: Training in English
Yocto: Training in English
 
Docman - The swiss army knife for Drupal multisite docroot management and dep...
Docman - The swiss army knife for Drupal multisite docroot management and dep...Docman - The swiss army knife for Drupal multisite docroot management and dep...
Docman - The swiss army knife for Drupal multisite docroot management and dep...
 
20150317 firefox os_studymtg_engver
20150317 firefox os_studymtg_engver20150317 firefox os_studymtg_engver
20150317 firefox os_studymtg_engver
 
git-and-bitbucket
git-and-bitbucketgit-and-bitbucket
git-and-bitbucket
 
CSE 390 Lecture 9 - Version Control with GIT
CSE 390 Lecture 9 - Version Control with GITCSE 390 Lecture 9 - Version Control with GIT
CSE 390 Lecture 9 - Version Control with GIT
 
IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with D...
IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with D...IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with D...
IBM Index 2018 Conference Workshop: Modernizing Traditional Java App's with D...
 
Introduction to Git and Github
Introduction to Git and Github Introduction to Git and Github
Introduction to Git and Github
 
Docker 1.5
Docker 1.5Docker 1.5
Docker 1.5
 
Analyze corefile and backtraces with GDB for Mysql/MariaDB on Linux - Nilanda...
Analyze corefile and backtraces with GDB for Mysql/MariaDB on Linux - Nilanda...Analyze corefile and backtraces with GDB for Mysql/MariaDB on Linux - Nilanda...
Analyze corefile and backtraces with GDB for Mysql/MariaDB on Linux - Nilanda...
 
Puppet at Opera Sofware - PuppetCamp Oslo 2013
Puppet at Opera Sofware - PuppetCamp Oslo 2013Puppet at Opera Sofware - PuppetCamp Oslo 2013
Puppet at Opera Sofware - PuppetCamp Oslo 2013
 
How to make debian package from scratch (linux)
How to make debian package from scratch (linux)How to make debian package from scratch (linux)
How to make debian package from scratch (linux)
 
eZ Publish 5: from zero to automated deployment (and no regressions!) in one ...
eZ Publish 5: from zero to automated deployment (and no regressions!) in one ...eZ Publish 5: from zero to automated deployment (and no regressions!) in one ...
eZ Publish 5: from zero to automated deployment (and no regressions!) in one ...
 
Road to Opscon (Pisa '15) - DevOoops
Road to Opscon (Pisa '15) - DevOoopsRoad to Opscon (Pisa '15) - DevOoops
Road to Opscon (Pisa '15) - DevOoops
 

More from KalimuthuVelappan (8)

rdma-intro-module.ppt
rdma-intro-module.pptrdma-intro-module.ppt
rdma-intro-module.ppt
 
lesson24.ppt
lesson24.pptlesson24.ppt
lesson24.ppt
 
kerch04.ppt
kerch04.pptkerch04.ppt
kerch04.ppt
 
Netlink-Optimization.pptx
Netlink-Optimization.pptxNetlink-Optimization.pptx
Netlink-Optimization.pptx
 
memory_mapping.ppt
memory_mapping.pptmemory_mapping.ppt
memory_mapping.ppt
 
memory.ppt
memory.pptmemory.ppt
memory.ppt
 
stack.pptx
stack.pptxstack.pptx
stack.pptx
 
lesson05.ppt
lesson05.pptlesson05.ppt
lesson05.ppt
 

Recently uploaded

Artificial Intelligence: Facts and Myths
Artificial Intelligence: Facts and MythsArtificial Intelligence: Facts and Myths
Artificial Intelligence: Facts and Myths
Joaquim Jorge
 

Recently uploaded (20)

The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024The 7 Things I Know About Cyber Security After 25 Years | April 2024
The 7 Things I Know About Cyber Security After 25 Years | April 2024
 
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time AutomationFrom Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
 
GenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day PresentationGenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day Presentation
 
Factors to Consider When Choosing Accounts Payable Services Providers.pptx
Factors to Consider When Choosing Accounts Payable Services Providers.pptxFactors to Consider When Choosing Accounts Payable Services Providers.pptx
Factors to Consider When Choosing Accounts Payable Services Providers.pptx
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
 
What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?
 
How to convert PDF to text with Nanonets
How to convert PDF to text with NanonetsHow to convert PDF to text with Nanonets
How to convert PDF to text with Nanonets
 
🐬 The future of MySQL is Postgres 🐘
🐬  The future of MySQL is Postgres   🐘🐬  The future of MySQL is Postgres   🐘
🐬 The future of MySQL is Postgres 🐘
 
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)
 
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
 
Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdfThe Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
 
08448380779 Call Girls In Friends Colony Women Seeking Men
08448380779 Call Girls In Friends Colony Women Seeking Men08448380779 Call Girls In Friends Colony Women Seeking Men
08448380779 Call Girls In Friends Colony Women Seeking Men
 
Artificial Intelligence: Facts and Myths
Artificial Intelligence: Facts and MythsArtificial Intelligence: Facts and Myths
Artificial Intelligence: Facts and Myths
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CV
 
Presentation on how to chat with PDF using ChatGPT code interpreter
Presentation on how to chat with PDF using ChatGPT code interpreterPresentation on how to chat with PDF using ChatGPT code interpreter
Presentation on how to chat with PDF using ChatGPT code interpreter
 
Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024Tata AIG General Insurance Company - Insurer Innovation Award 2024
Tata AIG General Insurance Company - Insurer Innovation Award 2024
 
Slack Application Development 101 Slides
Slack Application Development 101 SlidesSlack Application Development 101 Slides
Slack Application Development 101 Slides
 
Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024
 

DPKG caching framework-latest .pptx

  • 1. DPKG Caching Framework - Kalimuthu Velappan (Broadcom) - Greg Paussa (Broadcom)
  • 2. Introduction • Key feature of SONiC build • Plug-and-play of a module • Inter-module dependency through .deb packages • What’s missing in SONiC? • No incremental build support ( Any change in source will trigger rebuild from scatch) • Long time to build • DPKG caching framework provides an infrastructure to cache the SONiC module/target/docker .deb files into a local cache • Module/Target Dependency file tracking • Inter-module dependency • Environment variable changes • Two-level caching support • Support for true incremental build • Overall build time reduction
  • 3. SONiC Build Framework • Each module compiles the source code and generates the .deb package • Main .deb package and zero or more derived packages • Clean compilation( no incremental support) • From the .deb packages • sonic-<image>.bin • docker-<image(s)>.gz SONiC Build Module(s) (e.g. linux, libnl ,etc.) Compile and build .deb Build Artifacts target/debs/module(s).deb Docker Images target/docker-images(s).gz SONiC Image target/sonic-<vendor.bin>
  • 4. SONiC Build Organization 1. SONiC repo • Source code is part of repo • Build and generate the .deb package 2. Non-SONiC repo • Download the source file • Apply the patch files • Build and generate the .deb package 3. Non-source files • Download the .deb file directly from web or remote server
  • 5. SONiC DPKG Caching Framework SONiC Build Module(s) (e.g. linux, libnl, etc.) Compile and build .deb Build Artifacts target/debs/module(s).deb Docker Images target/docker-images(s).gz SONiC Image target/sonic-<vendor.bin> Module(s) .deb Cache Cache framework Module(s) dependency files
  • 6. Git Database Commands • To get the SHA value of a file: hash-object # git hash-object slave.mk some-new-file.txt ef2de5371650c4460dea3ad3887a4d6d57cbc845 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 • To get all the files in a module: ls-files # git ls-files -cms src/bash 100644 9395dcd541987faae588462a63d06c303b11cebe 0 src/bash/Makefile 100644 253475b21878b3373c21f9ec7ba6ad14c220cbdd 0 src/bash/patch/series 100644 2a19c9e70d3c38572f81a7c62cb722e5c80f939c 0 src/bash/patch/readline.patch • To get the modified files in a module: status # git status -s src/bash M src/bash/Makefile
  • 7. Dependency Tracking Dependencies > Target deb Common Dependencies ( rules/config , slave.mk, rules/functions ) ENV Flags (SONIC_DEBUGGING_ON, SONIC_PROFILING_ON , etc.) Load deb from cache Not modified Compile and build deb Modifed Dependency SHA Module Dependencies ( Makefile, debian/rules, srcs, patch files, etc.) DPKG Cache
  • 8. Derived .deb(s) Dependency Generation • Use git ls-files command to get the list of files for a module • Add package specific dependency files .mk, .dep, etc. <target> ( Eg: bash) rules/<target>.dep rules/<target>.mk target/debs/stretch/<target>.deb target/debs/stretch/<target>.deb .dep target/debs/stretch/<target>.deb .dep.sha
  • 9. Dependency Generation BASH src/bash/Makefile src/bash/patch/series src/bash/patch/readline.patch rules/bash.mk rules/bash.dep target/debs/stretch/bash-4.3-14_amd64.deb.dep 9395dcd541987faae588462a63d06c303b11cebe src/bash/Makefile 253475b21878b3373c21f9ec7ba6ad14c220cbdd src/bash/patch/series 2a19c9e70d3c38572f81a7c62cb722e5c80f939c src/bash/patch/readline.patch git ls-files src/bash target/debs/stretch/bash-4.3-14_amd64.deb.dep.sha target/debs/stretch/bash-4.3-14_amd64.deb 24 byte SHA git hash-object target/debs/stretch/bash-4.3-14_amd64.deb.dep.sha SONIC_DEBUG_ON=y SONIC_PROFILE_ON=N target/debs/stretch/bash-4.3-14_amd64.deb.flags Dependencies (DEPENDS, RDEPENDS etc) 24 byte SHA /cache/bash-4.3-14_amd64.deb-<24B sha>-<24B sha>.tgz git hash-object <dep files>
  • 10. Dependency File Generation • rules/<target>.mk • rules/<target>.dep SPATH := $($(BASH)_SRC_PATH) DEP_FILES := $(SONIC_COMMON_FILES_LIST) rules/bash.mk rules/bash.dep DEP_FILES += $(SONIC_COMMON_BASE_FILES_LIST) DEP_FILES += $(shell git ls-files $(SPATH)) $(BASH)_CACHE_MODE := GIT_CONTENT_SHA $(BASH)_DEP_FLAGS := $(SONIC_COMMON_FLAGS_LIST) $(BASH)_DEP_FILES := $(DEP_FILES) rules/bash.dep # Common Files # rules/config, slave.mk, rules/functions etc. # Base Files # sonic-slave*/Dockerfile*, # Common Flags # SONIC_DEBUGGING_ON, SONIC_PROFILING_ON etc. BASH_VERSION_FULL = 4.3-14 BASH = bash_$(BASH_VERSION_FULL)_amd64.deb $(BASH)_SRC_PATH = $(SRC_PATH)/bash SONIC_MAKE_DEBS += $(BASH) rules/bash.mk
  • 11. Cache File Tracking The cache file is a compressed TAR ball of a module's target DEB file and its derived-target DEB files. The cache filename is constructed as follows: FORMAT: <module deb filename>-<24 byte SHA hash>-<24 byte SHA hash>.tgz Eg: linux-headers-4.9.0-9-2-common_4.9.168-1+deb9u3_all.deb-fa16f47c0b63fa16f47c0b63-fd21bb776fa16f47c0b6.tgz <24-byte SHA value> - derived from the following: DEPENDS, RDEPENDS, WHEEL_DEPENDS, PYTHON_DEBS, PYTHON_WHEELS DBG_DEPENDS, DBG_IMAGE_PACKAGES, LOAD_DOCKERS <24-byte SHA value> - derived from either of the following: GIT_COMMIT_SHA - SHA value of the last git commit ID if it is a submodule GIT_CONTENT_SHA - SHA value is generated from the content of the target dependency
  • 12. Support for Environmental Flags • Support for Environment flags • SONIC_DEBUGGING_ON = y • SONIC_PROFILING_ON = y • Etc. • Support for inter-module dependency changes • If Module B depends on Module A, any changes to module A will: • Skip cache loading for module A and B, and • Rebuild modules A and B
  • 13. Module Makefile • Module Makefile/Makefile.am • Must specify source files explicitly in Makefile • SRCS = $(wildcard *.c)  Not OK • SRCS = src1.c src2.c src3.c  OK
  • 14. Cache Hierarchy • Two-level cache hierarchy: • Global Caching • Committed changes • Module files are not modified • Cache location: • Outside of sonic-buildimage folder • Local Caching • Local changes prior to commit (doesn’t change the global cache - Development) • Module files are modified • Dependent target(s) updated • Cache location: • sonic-buildimage/target/cache
  • 15. Cache Disable • Global • rules/config file: • SONIC_DPKG_CACHE_METHOD=none • Build environment: • make SONIC_DPKG_CACHE_METHOD=none • Per-module • rules/<target>.dep file: • $(TARGET)_CACHE_MODE := none • To force a rebuild • Rebuild cache with latest changes: • make SONIC_DPKG_CACHE_METHOD=rebuild • Use when the source is modified outside the sonic ‘git repo’
  • 16. Cache Location • Can choose where to locate the DPKG cache: • Local tmp storage • /tmp/dpkg_cache • Local disk storage • /dpkg_cache • NFS mount • /mnt/dpkg_cache • Cache size • 3G (All the .debs) • Incremental
  • 17. Cache Cleanup • Recently used cache files are updated with newer timestamp. • The DPKG framework automatically touch the used cache files to current timestamp. • touch /<cache_path>/<cache_file>.tgz • Least-recently-used cache file cleanup command: • find <cache_path> -name “*.tgz” ! -mtime -7 –exec rm {} ; • Where: -mtime n => Files were modified within last n*24 hours . -mtime -7 => means ( -7 * 24 ) => Files were modified within last 7 days ! -mtime -7 => Files were modified 7 days ago
  • 18. Build Time Comparison • Cached Build • SSD / 48 Core • BUILD_JOBS=48, MAKE_JOBS=48 • 8 Minutes • SSD / 16 Core • BUILD_JOBS=16, MAKE_JOBS=16 • 12 Minutes • Fresh Build • SSD / 48 Core • BUILD_JOBS=48, MAKE_JOBS=48 • 55 Minutes • SSD / 16 Core • BUILD_JOBS=16, MAKE_JOBS=16 • 80 Minutes (1.20 )
  • 19. Phase II • The final target/<vendor>-sonic.bin image generation takes around 10 minutes. • rootfs segregation • DPKG package database migration • Base rootfs (Cached) • SONiC fs • DPKG database fs
  • 20. Thank You Thanks to Greg Paussa(Broadcom) for the initial design of local caching for Linux kernel