Skip to content

Sandbox limits increase request for stm32 family crates #608

Closed
@adamgreig

Description

@adamgreig

Crate name: stm32f1, stm32f4, stm32h7, stm32g4
Build failure link: stm32f1 stm32f4 stm32h7 stm32g4

Requested RAM limit: stm32f1: 4GB, stm32f4: 5GB, stm32h7: 8GB, stm32g4: 5GB
Requested timeout: existing 15min limit is OK

Why your crate needs the resource increases:

These crates all belong to the stm32-rs group of crates, which are "peripheral access crates" for embedded Rust projects using STM32 microcontrollers. The crates contain functions for accessing every hardware register on the relevant microcontroller, for all microcontrollers in a family (e.g. the STM32F4 family). Some families have many members or especially many hardware registers, so take a lot of memory to build.

I built all the crate docs in a local sandbox and measured memory usage, which is what the requested RAM limits above are based on:

stm32f0: 1m27s 2361MB (OK on docs.rs)
stm32f1: 2m33s 3356MB (Failed on docs.rs)
stm32f2: 1m32s 2345MB (OK on docs.rs)
stm32f3: 1m12s 1807MB (OK on docs.rs)
stm32f4: 3m11s 4136MB (Failed on docs.rs)
stm32f7: 2m26s 3024MB (OK on docs.rs)
stm32h7: 8m46s 7121MB (Failed on docs.rs)
stm32l0: 1m36s 2178MB (OK on docs.rs)
stm32l1: 1m15s 1878MB (OK on docs.rs)
stm32l4: 1m30s 2287MB (OK on docs.rs)
stm32g0: 1m45s 2500MB (OK on docs.rs)
stm32g4: 3m32s 4542MB (Failed on docs.rs)

At present we already use the docs.rs metadata field in Cargo.toml to select only a few device features for each crate. Ideally we would select every device so they are all documented, but this compromise helps reduce build time/disk space/memory required while still documenting the most popular devices. If it's possible to have slightly higher memory limits on more of the crates (e.g., 8GB for all the crates in the family), we could add more devices to be documented.

As an aside, if it were possible to only build these crates for a single platform (#532), that would be great: we don't emit anything different for the other platforms and it would presumably save a load of time and disk. I'm very aware that every release clogs up your build queue for a few hours!

Thank you so much for running this brilliant resource, I use docs.rs every day and it's incredibly useful.

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-limits-increaseCategory: A crate needs a limits increase to build successfully

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions