So, a few comments:
1) Just as a quick note - MAP_NORESERVE doesn't help things any here. The lazy swap reservation gets the swap in the middle of the mlock path but gets treated the same way as the swap reservation in the first place -- if disk swap is available, it will reserve there [even though the lockable stole from swapmem anyway, yes].
2) I'm not going to dig through every design note ever on this to say with 100% certainty why it is the way it is. There are benefits to this design in that it ensures simple and clean backout operation (without risk of resources being unavailable in operations you can't fail for lack of resources [like munlock() or more interesting munmap() or exit() -- and before you say "Well, why would you need resources if you're going away?" keep in mind a single mlock on a Shared object which has many other attached references means objects don't always go away on a single exit()]. It also simplifies the model with regards to having to track what is swap-backed versus what isn't (private page copies within a file versus file-backed shared pages, etc.).
3) One other factor here that is less obvious is that preserving memory swap for lockable memory clients and most importantly for kernel memory allocations is a higher priority than preserving swap reservation space as a general rule. (If you run out of memory swap and need more kernel space to make progress, you're out of luck - so the system tries to avoid that). This is why memory swap is reserved after all disk/FS swap reservation space is used and why the system will actually migrate memory swap backed reservations to disk/FS backed reservations where it can over time if the swap needs peak and then recede.
4) Harkening back to (1) for a moment, the system is smart enough not to double-book memory swap, however -- as if the object is already using memory swap, there's no real gain in holding more as long as it isn't incorrectly released. If there were a mmap() or shm or whatnot flag for forcing memory swap reservations, you'd see your reservations be only what you need. Since there isn't, of course, you can't see that unless you want to do an experiment where you consume all your disk swap first. Since this wouldn't be reliable in practice -- I wouldn't recommend you bother.
5) So, after all those comments and back on point -- while I can see why it was done this way and wouldn't call it just "laziness" (there's a clear factor of diminishing risk in this sort of complex accounting) -- I would personally agree that this is suboptimal and the system can do better. As such, I'd ask that you do suffer through the Support process enough to get them to log this as an actual customer found issue (it is good to have a real customer on this sort of thing so the trade offs between the risk of changing the behavior and the benefits of resolving the issue can be weighed correctly).
