On Sun, 2025-02-02 at 21:47 -0800, Andi Kleen wrote: > > > > If I reading this right, calls to get_next_line lead to insertions > > into > > the ring buffer whilst the buffer is empty or the last line in the > > ring > > buffer cache is m_line_num - 1. > > > > There are a few places where we update m_line_num, but this caching > > code doesn't seem to touch those places. Should it? I don't know > > if > > the lack of a reset is an issue, but it's an aspect of the patch > > that's > > a bit hazy to me; sorry. > > The idea was that there is only a single cursor for this cache, > assuming the main parser algorithm goes linearly through the file. > > So even if m_line_num changes temporarily for some warning > it will eventually go back to where that cursor was. So > I didn't bother to refill the cache on these changes. > > There is a good chance that the changed position hits the cache > if it's within its range. > > If there is an access pattern where this assumption is not true > the cache will not work, but the normal anchors still do of course. > > I will add a comment describing this. > > > If I'm reading this right, the caching that this adds is only for > > the > > final 256 lines read so far in the file, and lets us use a line > > offset > > relative to the most recent entry to go direct to such a recent > > line in > > the file. > > Right.
Thanks; the patch is OK for trunk (with the comment added). Dave
