michaeljmarshall commented on PR #16145: URL: https://github.com/apache/lucene/pull/16145#issuecomment-6462845779
Thanks for your review @pauldoo. I agree that reducing risk while providing incremental improvement is a good way to think about the `SKIP` value. It's also valuable to compare the cost of the `mincore` call to the cost of blind major page faults. Assume a residency probe costs 2 µs and an avoidable major fault costs 100–300 µs. While the file remains warm, we can expect: | `SKIP` | Amortized probe cost per call | |---:|---:| | 64 | 31.25 ns | | 128 | 15.63 ns | | 256 | 7.81 ns | | 512 | 3.91 ns | | 1024 | 1.95 ns | After eviction (one-time cost per transition, assuming eviction occurs uniformly between probes): | `SKIP` | Expected silent misses | At 100 µs/miss | At 300 µs/miss | |---:|---:|---:|---:| | 64 | 32 | 3.2 ms | 9.6 ms | | 128 | 64 | 6.4 ms | 19.2 ms | | 256 | 128 | 12.8 ms | 38.4 ms | | 512 | 256 | 25.6 ms | 76.8 ms | | 1024 | 512 | 51.2 ms | 153.6 ms | Worst-case transition costs are approximately twice the averages. These are modeled serial costs, not necessarily wall-clock latency under concurrency. And note that it is likely we could see cases where the file experiences partial page cache churn, which might reduce the latency cost but would also reduce the effectiveness of the probe. Moving from 256 to 1024 therefore saves about 6 ns per warm prefetch call, but quadruples the expected cost of detecting eviction. During a change in memory pressure, all files independently discover such a change, so the larger the `SKIP` value, the more stacked latency a search could encounter. With this analysis, perhaps 256 is a reasonable middle ground given the various comments that have mentioned that value? -- 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]
