On Fri, Feb 17, 2012 at 10:01:49PM +0600, Anton Maksimenkov wrote: > I want to ask you about vmmap changes introduced here and in your > presentation http://openbsd.org/papers/tdose_memalloc/presentation.html > > 1. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2816%29 > "Browsers, java & mono breakage" > You pointed to some buggy software. If I understand correctly, you try > to "workaround" these bugs by using of "VM map address selectors". > If it is correct then I don't see reasons for this code and it's > "workarounds overhead"
You're assuming every work around has significant overhead. The overhead of this mechanism is that it's separated into a different module, controlled with a few function pointers. > in production (web/db server, firewall, > router... ) where these buggy apps don't used at all. > Secondly vmmap becomes more complex and harder to understand/debug/develop. Actually, the vmmap becomes easier to debug and develop. The separation of the logic makes it easier to develop address selectors for instance (address selectors are the little bits of code which choose which address an allocation happens to receive). Therefore the code in the mapping part (uvm_map.c) only deals with mapping, making it easier to read and grasp. After all, now the uvm_map.c only deals with keeping track of mappings, faulting and related issues, but not the address selection. And uvm_addr.c deals only with address selection, but not with all the other things. > Maybe these "workarounds" must be #ifdef'ed and enabled only by some > kernel option? That's stupid. Complexity (big O) in code is negligable, while adding #ifdefs would reduce understandibility (programmer comprehension) in code. > 2. http://openbsd.org/papers/tdose_memalloc/presentation.html#%2828%29 > "Pivot algorithm" > For what reason this code used for? Why we can't select some random > entry from freespace and some random offset (as you say in > http://openbsd.org/papers/tdose_memalloc/presentation.html#%2827%29)? About a third of the presentation deals with this model: Your suggested algorithm was the first thing I tried: slides 13 and 14. Why it breaks: slides 15 - 21. Slide 22, deals with the additional requirements from the aforementioned slides. Slide 23, splitting the logic, in order to make it easier to develop different algorithms and decouple the two. With regard to the design, I don't think you can easily change that now. I've worked on it a long time, it cost a lot of effort and work to get it done. The most useful input to me, right now, is either testing it, informing me where it fails. Or better yet: code reviews (you know how hard it is to get someone to review 10k LoC of diff)? -- Ariane
