Hi, On Tue, Feb 25, 2025 at 12:39:04PM +0000, Dave Martin wrote: > Hi Tony, > > On Mon, Feb 24, 2025 at 05:23:06PM +0000, Luck, Tony wrote: > > > It has just occurred to be that ftrace has large, multi-line text files > > > in sysfs, so I'll try to find out how they handle that there. Maybe > > > there is some infrastructure we can re-use. > > > > Resctrl was built on top of "kernfs" because that was a simple base > > that met needs at the time. > > > > Do we need to look at either extending capabilities of kernfs? Or > > move to sysfs? > > > > -Tony > > I took a look at what ftrace does: it basically rolls its own buffering > implementation, sufficient for its needs. > > The ftrace code is internal and not trivial to pick up and plonk into > resctrl. We also have another possible requirement that ftrace doesn't > have (whole-file atomicity). But ftrace's example at least confirms > that there is probably no off-the-shelf implementation for this in the > kernel. [...] After having spent a bit of time looking into this, I think we are probably OK, at least for reading these files. seq_file will loop over the file's show() callback, growing the seq_file buffer until show() can run without overrunning the buffer. This means that the show() callback receives a buffer that is magically big enough, but there may be some "speculative" calls whose output never goes to userspace. Once seq_file has the data, it deals with the userspace- facing I/O buffering internally, so we shouldn't have to worry about that. I'll try to hack up a test next week to confirm that this works. The seq_file approach appears sound, but may be inefficient if the initial guess at the buffer size (= PAGE_SIZE) is frequently too small. (There is single_open_size() though, which allows the buffer to be preallocated with a specified size and may be useful.) seq_file doesn't help with the write side at all, but I think we agreed that handling large file writes properly is less urgent. Cheers ---Dave
