One big pool or several type specific pools?

The correct answer is specific to your problem domain. But in the problem domains that I work, the first is usually the one we choose.

I do realtime or near realtime code. Audio editing and playback mostly. In in that code, we generally cannot afford to allocate memory from the heap down in the playback engine. Most of the time malloc returns fast enough, but sometimes it doesn't. And that sometimes matters.

So our solutions is to have specific pools for certain objects, and use the general pool for everything else. The specific pools have a certain number of elements preallocated, and are implemented as a linked list (actually a queue), so allocation and release is never more than a couple of pointer updates and the cost of entering and leaving a critical section.

As a fallback for unusual cases; when someone needs to allocate from a special pool and it's empty - we will allocate a hunk of general memory (several objects) and add that to the special pool. Once an allocation is part of the special pool, it is NEVER returned to the general pool until the app exits or starts a new project.

Making good choices about the initial size and maximum size of the special pools are an important part of tuning the application.

One problem that you'll run into is that STL implementations are allowed to assume that two allocators of the same type are equivalent. This is the reason that Boost.Pool uses only one pool (technically it uses a different pool for each type). I.E., your allocators are not allowed to have any non-static members in the general case. If you're making a video game and you know that your STL implementation does not have this problem, then don't worry about this -- however there might still be some issues with list::splice and std::swap on containers.

It's not practical to use stl or boost for any type of video game, for starters. You can be absolutely sure the second you use one stl container your memory is fragmented and your performance is hopelessly in the toilet compared to the ideal at least (since most everyone's code is in this category most people never notice and can't really compare to anything else). I didn't always think so strongly but over time I have seen even a couple lines of code is like a little gremlin that will eventually some day cause you great pain.

The first method is most common, and as someone who's done both it's probably the only way that's practical if you don't want to spend a lot lot LOT more time and energy on the problem than it's probably worth to you. The second way is better because it's more general and yet can be tailored to your exact needs, but it's a lot of work and not something to jump into lightly.