On Mon, Mar 21, 2016 at 5:12 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Sun, Mar 20, 2016 at 3:01 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Sat, Mar 19, 2016 at 7:02 PM, Robert Haas <robertmhaas@gmail.com> wrote: > >> On Sat, Mar 19, 2016 at 12:28 AM, Amit Kapila <amit.kapila16@gmail.com> > >> wrote: > >> > Won't in theory, without patch as well nentries can overflow after > >> > running > >> > for very long time? I think with patch it is more prone to overflow > >> > because > >> > we start borrowing from other free lists as well. > >> > >> Uh, I don't think so. Without the patch, there is just one entries > >> counter and it goes up and down. How would it ever overflow? > > > > I thought it can overflow because we haven't kept any upper limit on > > incrementing it unless the memory finishes (ofcourse that is just a > > theoretical assumption, as the decrements will keep the number in control), > > so are you thinking about the risk of overflow with patch because we have to > > use sum of all the nentries from all the arrays for total or is there any > > thing else which makes you think that changing nentries into arrays of > > nentries can make it prone to overflow? > > Well, I mean, perhaps nentries could overflow if you had more than > 2^32 elements, but I'm not even positive we support that. If you > assume a fixed table with a million entries, the nentries value can > vary only between 0 and a million. But now split that into a bunch of > separate counters. The increment when you allocate an entry and the > decrement when you put one back don't have to hit the same bucket,
>
This is the point where I think I am missing something about patch. As far as I can understand, it uses the same freelist index (freelist_idx) for allocating and putting back the entry, so I think the chance of increment in one list and decrement in another is there when the value of freelist_idx is calculated differently for the same input, is it so, or there is something else in patch which I am missing?