On Thursday 04 September 2014 01:07:49, Branko Čibej wrote: > On 03.09.2014 23:15, Stefan Fritsch wrote: > > On Wednesday 03 September 2014 15:37:17, Jim Jagielski wrote: > >> It's now ~6 years later and so wondering if just bypassing > >> the pool freelist is now viable, at least as a compile-time > >> (or allocator) option. > > > > I don't see any reason against a non-default compile-time option. > > Then people could test it more easily and give feedback. > > I do. Distro packages will tend to pick one or the other option, and > if applications have no control over the behaviour, they'll > mysteriously behave differently on different platforms (or even > different distros of the same OS).
Unfortunately without a compile time option, you won't get enough testing. And any significant change in the allocator will cause a problem in some workload. > We had, and possibly still have, the same problem with using mmap > for pool allocation; I've seen an application mysteriously fail on > some Linux distro because it "ran out of file handles", but turned > out to be hitting a hard limit of the number of mmapped blocks > (i.e., pools) per process. Because the distro packager happened to > turn mmap for pools on at compile time. I could never reproduce that issue. AFAICT, it is/was a kernel bug in some Linux versions. And the mmap allocator behaves significantly better in general (at least for httpd). Maybe it should be made the default, at least on linux. > I don't think it's a good idea to put potential heisenbugs into the > code by design. :) > > -- Brane
