> Won't it always use the same freelist to remove and add the entry from > freelist as for both cases it will calculate the freelist_idx in same > way?
No. If "our" freelist is empty when we try to remove an item from it we borrow item from another freelist.
I think the way patch works is if indicated freelist is empty, then it tries to allocate new elements in that list and if it can't allocate, then it tries to borrow from other freelist and in both cases the element to be removed from freelist is considered to be the element of indicated freelist (basically it always increment nentries[freelist_idx]).
Then this borrowed item will be returned to "our" freelist instead of original. Without some sort of additional logic there is no way to figure out what freelist was original.
As the patch always operates on nentries[freelist_idx], so it seems to me that in both cases (remove, add), the element is considered to be belonging to same freelist. Have you faced this problem of negative entries in any of your test, if so then share the test, so that I can also understand the scenario?
Generally speaking negative nentries value is not something that couldn't be solved. But I would like to remind that in this context we are discussing a quick and dirty solution created for benchmark purposes in a first place.
I thought negative entries could be a problem for the patch as indicated by Robert[1], but may be I am missing something.
> You are not convinced, then lets leave it to committer unless > somebody else wants to try that suggestion.
Agree. Frankly I'm tired of rewriting this patch over and over and over again. So I would like to avoid rewriting it once again unless there is a clear indication that this way we would gain something. Benchmarks shows that this is not a case thus it's only a matter of taste and intuition.
I can understand your feeling here and agree with you that it is a matter of taste. However, many a times if we change the patch according to committer's taste, the chances of patch getting accepted early is better, but I am not sure if that applies here, so feel free to go in the way you think is better.
