On Mon, Jun 28, 2021 at 12:44:22PM -0700, John Hubbard wrote: > On 6/28/21 12:33 PM, Matthew Wilcox wrote: > ... > > > > I wonder if single-byte captures enough of the useful possibilities. > > In the kernel we have memset32() and memset64() [1] so we could support > > a larger pattern than just an 8-bit byte. It all depends what userspace > > would find useful. > > > > [1] Along with memset_p(), memset_l() and memset16() that aren't terribly > > relevant to this use case. Although maybe memset_l() would be the right > > one to use since there probably aren't too many 32-bit apps that want > > a 64-bit pattern and memset64() might not be the fastest on a 32-bit > > kernel). > > > > And in fact, I'm also rather intrigued by doing something like 256 copies > of a 16-byte UUID, per 4KB page. In other words, there are *definitely* > useful patterns that are longer than a single byte, and it seems interesting > to support them here. > > Kirill's idea of an API that somehow allows various power of 2 patterns seems > like it would be nice, because then we don't have to pick a value that seems > good in 2021, but less good as time goes by, perhaps. > > Another thought is to use an entire 4KB page as the smallest pattern unit. > That would allow the maximum API flexibility, because the caller could > explicitly set every single byte in the page. That's what this patch does. If it can be reduced to a pattern (in Peter's patch of a single byte; i'm proposing expanding that), then the page is filled with the pattern; otherwise we copy the reference page.
