At Thu, 1 Oct 2020 04:20:27 +0000, "[email protected]" <[email protected]> wrote in > From: Kyotaro Horiguchi <[email protected]> > > In more detail, if smgrcachednblocks() returned InvalidBlockNumber for > > any of the forks, we should give up the optimization at all since we > > need to run a full scan anyway. On the other hand, if any of the > > forks is smaller than the threshold, we still can use the optimization > > when we know the accurate block number of all the forks. > > Ah, I got your point (many eyes in open source development is nice.) Still, > I feel it's better to treat each fork separately, because the inner loop in > the traditional path may be able to skip forks that have been already > processed in the optimization path. For example, if the forks[] array > contains {fsm, vm, main} in this order (I know main is usually put at the > beginning), fsm and vm are processed in the optimization path and the inner > loop in the traditional path can skip fsm and vm.
I thought that the advantage of this optimization is that we don't need to visit all buffers? If we need to run a full-scan for any reason, there's no point in looking-up already-visited buffers again. That's just wastefull cycles. Am I missing somethig? > > Still, I prefer to use total block number of all forks since we anyway > > visit the all forks. Is there any reason to exlucde forks other than > > the main fork while we visit all of them already? > > When the number of cached blocks for a main fork is below the threshold but > the total cached blocks of all forks exceeds the threshold, the optimization > is skipped. I think it's mottainai. I don't understand. If we chose to the optimized dropping, the reason is the number of buffer lookup is fewer than a certain threashold. Why do you think that the fork kind a buffer belongs to is relevant to the criteria? regards. -- Kyotaro Horiguchi NTT Open Source Software Center
