burn_backend/backend/
memory_pools.rs

1//! What a device's dynamic memory pools held.
2//!
3//! An allocator that only grows keeps whatever page it ever needed, so a
4//! long-running workload reserves its worst moment for life. These types read
5//! back what a workload actually held, so what its pages cost is a measurement
6//! rather than a guess.
7//!
8//! The vocabulary is the backend's own rather than any runtime's, since
9//! [`Backend`](super::Backend) is also implemented by backends with no pools at
10//! all.
11
12/// One dynamic pool's measured state, in the order allocations are routed
13/// through the pools.
14#[derive(Clone, Copy, Debug, Default, PartialEq, Eq)]
15pub struct SlicedPoolReport {
16    /// Size of each page in bytes.
17    pub page_size: u64,
18    /// Pages currently held.
19    pub pages: u64,
20    /// The most pages ever held at once.
21    pub pages_peak: u64,
22    /// The largest single allocation served, in requested bytes.
23    pub largest_alloc: u64,
24}
25
26/// One reading of a device allocator's state, across the runtime's streams and
27/// pools.
28#[derive(Clone, Copy, Debug, Default, PartialEq, Eq)]
29pub struct MemoryPoolUsage {
30    /// Live allocations, not pages.
31    pub number_allocs: u64,
32    /// Bytes those allocations use, excluding padding.
33    pub bytes_in_use: u64,
34    /// Bytes of padding inside them.
35    pub bytes_padding: u64,
36    /// Total bytes reserved on the device: at least `bytes_in_use`, plus pages
37    /// held for reuse.
38    pub bytes_reserved: u64,
39}
burn_backend/backend/memory_pools.rs

burn_backend/backend/
memory_pools.rs
