On 1/28/16 1:47 PM, Sam Ravnborg wrote: > 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? > I was just concerned that fixing 8M might be more work than getting hw-supported 4M pages to work and since 4M->8M transition did not seem to be based on very fundamental reasons, I believed directly going for 4M pages while disabling THP temporarily (currently it doesn't really work great on sparc/linux anyways) would be worth it. Anyways, I did make a quick hack to enable 4M pages and I see CPU lockups with same stack trace so I guess they both have same underlying cause, so I'm now okay with fixing 8M case first. Thanks, Nitin -- 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
