Re: [RFC] hugepages on sparc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



From: Sam Ravnborg <sam@xxxxxxxxxxxx>
Date: Thu, 28 Jan 2016 22:47:24 +0100

> 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.

I totally agree.

It is _ABSOLUTELY_ _WRONG_ to respond to a bug in THP support by changing
the huge page size.

That is just pure insanity.

Instead, figure out what the bug is an _FIX_ it.

I refuse to entertain any patches presented to me that change the huge
page size without:

1) Fixing the current bug.

2) Seeing if the 8MB performance meets your expectations.

Nitin, your focus is completely in the wrong place.  You cannot even
see how 8MB performs yet you think it's not appropriate to use that as
the THP page size.

That's not logical, and that's not good engineering.

So please stop this obsession with changing the THP page size now,
thanks.
--
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



[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux