sbitmap_que...hallow_depth(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… sbitmap_queue_min_shallow_depth(9) πŸ’…

okay bestie, welcome to the Kernel API Manual ✨ this one's a lil function called sbitmap_queue_min_shallow_depth, and honestly? she's short but she MATTERS. let's get into it 🫢


🌸 NAME 🌸

sbitmap_queue_min_shallow_depth β€” the way you inform a &struct sbitmap_queue about the minimum shallow depth that's gonna get used πŸ“βœ¨


πŸŽ€ SYNOPSIS πŸŽ€

void sbitmap_queue_min_shallow_depth (struct sbitmap_queue *sbq ,
unsigned int min_shallow_depth );

no cap, that's the whole signature πŸ’…


πŸ¦‹ ARGUMENTS πŸ¦‹

  • sbq β€” the bitmap queue in question. like, the one you're talking about. the main character of this call πŸ‘‘
  • min_shallow_depth β€” the minimum shallow depth that will be passed to sbitmap_queue_get_shallow or __sbitmap_queue_get_shallow. yes, that exact one, don't get creative πŸ™ˆ

πŸ”₯ DESCRIPTION πŸ”₯

so here's the tea β˜• β€” sbitmap_queue_clear batches wakeups as an optimization, right? and the batch size depends on the depth of the bitmap. iconic of her, truly.

but the shallow allocation functions effectively operate with a different depth, so the shallow depth has to be taken into account when calculating that batch size. the math does NOT math otherwise πŸ’€

⚠️ so this function must be called with the minimum shallow depth that will actually be used. failure to do so can result in missed wakeups. and missed wakeups are NOT the vibe, bestie 😭

🌈 SEE ALSO 🌈

the whole friend group, fr fr 🫢:


and that's the whole page, periodt πŸ’– this little icon lives in ./include/linux, dated October 2026, and it's serving sbitmap_que...hallow_depth(9) energy all day long πŸ§šβ€β™€οΈβœ¨ slay, go set your shallow depth correctly πŸŽ€

πŸ“¦ where this page comes from