goankur commented on PR #16145: URL: https://github.com/apache/lucene/pull/16145#issuecomment-6226191022
> I considered a position based hash, but I preferred the counter/seed solution. The hash(offset) solution is deterministic for a given offset and relies on variation of the offset to probe but still only ever probes for the same offsets ... Agreed, the counter is the better choice. A small nuance: a miss on a sampled page resets the whole file to probing every call, so the hash doesn't end up keeping only those pages warm. Its real weakness is coverage: if a file's hot pages all hash outside the sampled set, which is likely for small files, nothing probes it while it's confident. In my runs the two performed the same, and staggering the seeds per input should take care of most of the cycle problem. > What are the use cases where a file starts warm in the page cache? In my mind, these are the ones just written by flush or by merge. In the flush case, those files are likely to be small ... Flush and merge are the main ones, plus files copied in by replication or recovery, and every file after a process restart while the OS cache is still warm. That last case is common for indexes that fit in memory. Merged files and files opened after a restart are often large, so a small-file branch would help flushes but not those. Executing `isLoaded` for small files as a whole still sounds reasonable to me. For larger files, a cheap option might be to probe a handful of pages at open and start confident if they're all resident. That said, since a wrong "warm" guess costs at most SKIP − 1 unprefetched reads, I'm not sure we need to predict this well at all. > I did have an agent look into whether it'd be easy to determine if a file was just written, but it didn't find anything satisfactory in the current feedback loops ... A recently-written hint could work if it lives in the Directory, which would also cover in-process replication. It still wouldn't cover files reopened after a restart, or files copied outside Lucene. Given how cheap a wrong "warm" guess is, I'd rather avoid that machinery. > Alternatively, we could consider a middle solution where we probe for fewer than 1024 calls but more than 3 calls (the current default). 1024 comes from the cost of a major page fault vs an unnecessary isLoaded call. I tried N = 128. With the search JVM in a cgroup capped at 10 GB (4 GB heap, the rest for page cache), rerank p99 went from ~17 to 47 ms. At 20 GB it went from ~6.6 to 52 ms. Skipping starts during warm-up, and the cache never settles. So I think 1024 is right. What hurts the hot case is the starting state, not N. > Also, what is the methodology you're using that justifies the start confident conclusion? When is an ... For methodology, I went after the worst case for starting confident: every file cold when it's opened. The rerank runs drop the page cache before each run, the cold luceneutil pairs ran in both orders, and your JMH cold scenario drops it before every iteration. I couldn't find a cost in any of them. Everything's in the [results branch](https://github.com/goankur/lucene/tree/pr16145-eval/results) if you want to dig in. Inputs come from MMapDirectory.openInput, which gets called when a segment reader opens its files, either at startup or on reopen. Clones and slices share the backoff. There's no real expectation that the file is hot. It often is, but not after a reboot or when the index is bigger than RAM. That's fine, though: guessing "warm" wrongly costs at most SKIP − 1 missed prefetches, while guessing "cold" wrongly costs 1024 probes on every open. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
