On Fri, Feb 26, 2010 at 12:52:56PM +0500, Anton Maksimenkov wrote: > 2010/2/26 Otto Moerbeek <[email protected]>: > >> 2. > ... > >> I think that we may introduce some variable - sysctl variable or > >> malloc.conf flag - which will prevent sys_mmap() or uvm_map_hint() > > If fragmentation really is a problem for you, my first reaction is: > > use a machine with a bigger adress spacce. > > No deal. amd64, for example, use same semantics - 2G userspace, If I > remember correctly.
No, amd64 has a MAXDSIZE of 8G these days. It could be increased even more. But that should probably wait until it can address more physcial mem. BTW, I'm not even sure if MAXDSIZE is or physsical mem is the real bound here. After all we're talking about the virtual address space. > But anyhow, it is not so good way. Let's see - I have i386 machine > with 2G ram. But I can't use more than 1G because postgres's > allocations may start faililg. It is not so funny. No, you can use more, but there are bounds on the amount of mem per process and the amount of shared mem etc. In practice this may mean that postgress is limited indeed. But see below. > > Sysadmin must have the possibility to change this behavour. > > > IMO, a flag for malloc(3) is not a good idea. Memory layout policy is a > > kernel task. > So, what is better? > > > As for reducing the gaps: if gaps area few pages max, in effect you > > are reducing randomness and increasing predictability of memory > > layout. I would hate too loose that. > I said about this - yes, it reduces and increases... but "sysadmin > must have the possibility to change this". Let he decide his needs. > Again, there are cases when you NEED use memory, and you agreed to pay > reducing randomness for that. Let sysadmin decide. > > And there are already some funny sysctl's - machdep.allowaperture, > machdep.userldt. > Probably it is not so scared to add variable for "shrink randomness"? > > 2010/2/26 Theo de Raadt <[email protected]>: > > I know what you want. You, me, we all want faster software. But at > > the cost of encouraging the software to become less reliable, less > > maintainable, less debuggable? No, you don't want that. When > > software crashes, I want to be able to fix it on the spot because the > > bug is obvious. So that you don't hit the bug. > > Totally agreed. And I do not argue that current behavour must be > changed. Let it be as it is by default! > > But I just want to add POSSIBILITY to change this. Let sysadmin decide > that in some case it NEED "shrink randomness", doesn't matter which > bugs _may_ will show themselfs. > Make sysadmin hack through kernel sources is not good. > Let it be sysctl variable. Or maybe kernel config option (remember > pptp port recommendations about kernel?). It must be some switch. > -- > antonvm I don't think you'll find much support here, Switches that reduce security are generally considered bad here. -Otto
