linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [LSF/MM/BPF TOPIC] Memory fragmentation with large block sizes
@ 2026-02-19  9:54 Hannes Reinecke
  2026-02-19 14:32 ` Theodore Tso
  2026-02-19 14:53 ` Bart Van Assche
  0 siblings, 2 replies; 5+ messages in thread
From: Hannes Reinecke @ 2026-02-19  9:54 UTC (permalink / raw)
  To: lsf-pc, linux-nvme, linux-block, linux-mm

Hi all,

I (together with the Czech Technical University) did some experiments 
trying to measure memory fragmentation with large block sizes.
Testbed used was an nvme setup talking to a nvmet storage over
the network.

Doing so raised some challenges:

- How do you _generate_ memory fragmentation? The MM subsystem is
   precisely geared up to avoid it, so you would need to come up
   with some idea how to defeat it. With the help from Willy I managed
   to come up with something, but I really would like to discuss
   what would be the best option here.
- What is acceptable memory fragmentation? Are we good enough if the
   measured fragmentation does not grow during the test runs?
- Do we have better visibility into memory fragmentation other than
   just reading /proc/buddyinfo?

And, of course, I would like to present (and discuss) the results
of the testruns done on 4k, 8k, and 16k blocksizes.

Not sure if this should be a storage or MM topic; I'll let the
lsf-pc decide.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2026-02-20  7:44 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-19  9:54 [LSF/MM/BPF TOPIC] Memory fragmentation with large block sizes Hannes Reinecke
2026-02-19 14:32 ` Theodore Tso
2026-02-20  7:44   ` Hannes Reinecke
2026-02-19 14:53 ` Bart Van Assche
2026-02-19 15:00   ` Matthew Wilcox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox