On Thu, Jan 28, 2016 at 11:22:52AM -0800, Nitin Gupta wrote: > > > On 01/27/2016 03:17 PM, David Miller wrote: > > From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx> > > Date: Wed, 27 Jan 2016 14:29:49 -0800 > > > > > > > I don't see what the problem with 8MB huge pages are, they work really > > well and the implementation is incredibly straightforward. > > > > You have to demonstrate a performance of behavioral problem to justify > > such work. Then you have to come up with an implementation of the > > THP ABI changes, and satisfy the THP and mm maintainers. > > > > 8M pages don't seem to work too well: > > I ran stream benchmark: > https://www.cs.virginia.edu/stream/ref.html > > On a SPARC T4 (128 CPUs, 128G RAM) running 4.5.0-rc1, I got CPU > lockups and the test seems to get stuck near initialization. The > same test completed on the same hardware in 1m53s with normal 8K > pages. The test allocates a total of 48G of RAM and I forced it > to use hugepages with 'hugectl --heap=8M'. I passed hugepages=8192 > as kernel boot param to make sure all 48G could be allocated with > hugepages. > > Since 8M seems not quite functional, I can work on getting back 4M > pages with hopefully decent performance. This would temporarily > break THP on sparc/linux but it would allow me to split the work > in phases. Before introducing anything new it would be good to have the current functionality fixed. Then you have something working that can be improved. And you seem to know the area, have access to HW and can reproduce the bug. So is this something you could at least try to spend some time on before starting a bigger rewrite? Sam -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
