> > > This diff implements a tradeoff to gain speed at the cost of reducing > > > the randomness of chunk allocation in malloc slightly. > > > > > > The idea is only to randomize the first half of chunks in a page. The > > > second half of chunks will fill in the gaps in-order. The > > > effectiveness of the current randomization decreases already with the > > > number of free slots diminishing in a page. > > > > > > In one test case, this diff reduced the runtime from 31s to 25s. I'm > > > not completely sure if the reduced randomness is acceptable. But if > > > > Perhaps a quarter? We want to prevent adjacent consecutive > > allocations, which is still very likely at the half way point, but > > diminishes after that. > > Yes, that might be better, though you some of the performance gain is > lost because you are scanning a lot of bits: i free bits + all bits in > between that are not free. If a chunk page is pretty full, that's a > lot of bits before you find the i'th free chunk. > > Originally I though most of the time was lost getting the random bits, > but now it seems the scanning of the bits is to blame. Unless I'm > misinterpreting my data....
Hi Otto, Now that OpenBSD defaults to use bigmem it will suffer from small page size on certain platforms like amd64, sparc64. What do you guys think if the page size is dynamically adjusted to the datasize of FFS1 i.e when I fire up disklabel it is by default 16Kb on FFS1 on amd64. And higher on FFS2 only systems? Or you could base it on RAM size detected on system. I don't know what's best, you guys know. If then you combine with your original/tedu@ suggestion of consecutive allocations nearing end of page, it would be best. Then, you have a bigger page size which packs in more allocations and also gives more room to randomize. Of course,there is the problem of guard pages where memory is wasted, if you have guard page size == normal page size. Guard page size could be current page size, which is 4096 on amd64. This would take care of almost all scenarios, including supporting old drives, current disks with massive cache, and upcoming world of SSDs. And the RAM sizes are exploding too, 8GB stick is becoming mainstream. IMHO, increasing the page size will lead to bigger sustainable gains. Thanks, amit
