On Mon, Jun 28, 2021 at 12:57 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > 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. That sounds good. I propose that for now we only optimize the single byte pattern and single MTE granule use cases, and allow future expansion later via the size argument. Programs that use sizes with optimizations only implemented on newer kernels will still work on older kernels; they will just be faster on the new kernels. Peter
