Commit Graph

3 Commits

Author SHA1 Message Date
Bastian Blank aed63a56b1 * debian/changelog: Update
* debian/config/kernelarch-powerpc/config-arch-64: Set PPC_64K_PAGES.
* debian/config/kernelarch-powerpc/config-arch-64-le: Remove overriden option.

svn path=/dists/trunk/linux/; revision=21721
2014-08-09 19:42:11 +00:00
Bastian Blank 895585e136 debian/config: Reorder config.
svn path=/dists/trunk/linux/; revision=21671
2014-08-03 19:05:53 +00:00
Ben Hutchings 0245fd5588 ppc64el: kernel: config: little-endian powerpc64 options
This config has options for little-endian PowerPC64 systems.
It shares most options with big-endian PowerPC64 systems.

The differences are:

- choice: Endianness selection
	Build a little endian kernel.

- choice: Page size
	64k pages have benefits (performance et al) over 4k pages on
	IBM POWER processors.

	The Debian ppc64el port primarily runs on this sort of hardware
	and chances are it will also run on hardware based on it (i.e.,
	OpenPOWER) [1] [2].

- Maximum number of CPUs
	This was increased to 2048 (following pseries_le_defconfig).

	For the currently announced systems, the number of CPUs range
	between 80-192 (1 or 2 processor module(s) * 10 or 12 cores
	per module * 8 threads per core) [3].  This is enough to have
	to diverge from CONFIG_NR_CPUS=32 in the other powerpc ports.

	For future systems, it's likely larger ones will be announced.
	The rationale: consider the announced systems are classified
	as 'scale-out' and 'entry-level', plus larger ones have been
	historically made available for addressing other markets; and
	notice the largest POWER7 server has 1024 CPUs (threads) [4],
	and that the threads-per-core doubled from POWER7 to POWER8.

	So, the 2048 value is a reasonable 'max' in that projection.
	Certainly it is greater than what would be required for most
	systems, but I belive 'max' makes sense in that case, if we
	are not looking for kernel rebuild and/with different config
	for the larger systems (although I would be ok with flavours).

- choice: Default CPUFreq governor
	As other architectures, we would prefer the default cpufreq
	governor to be 'ondemand'.

	The currently available cpufreq driver is for the PowerNV
	(non-virtualized) platform, where all processors are available.
	In that scenario, statically running at the highest frequency
	(specially on idle processors) is not very desireable for the
	hardware around (servers), and it is not unlikely for future
	hardware (possibly non-servers) to benefit too, considering
	that energy savings have been increasingly important on most
	environments.

	(Note: the powernv-cpufreq driver was introduced only in 3.15;
	       so, this option has no effect in 3.14; it is harmless.
	       I can put in patches for enabling this on 3.14 soon.)

- Apple PowerMac based machines
	This is being disabled temporarily, until a patch makes upstream
	(restricting it to 'depends on !CPU_LITTLE_ENDIAN').

	This hardware line has no (known) support for little endian
	mode currently, and disabling it has the useful effect of also
	disabling a lot of config options which 'depends on PPC_PMAC',
	thus saving tens of lines from changing config files.

	It indeed has to be disabled because it's enabled by default
	('depends on BOOK3S', 'default y'), so even changing it from
	config files would not be sufficient.

[1] 'OpenPOWER Foundation Unveils First Innovations and Roadmap'
    http://openpowerfoundation.org/press-releases/openpower-foundation-unveils-first-innovations-and-roadmap/
[2] 'POWER8 Reference Board now available for Development!'
    http://openpowerfoundation.org/technical/related-links/
[3] 'IBM Power System S812L and S822L'
    http://www-03.ibm.com/systems/power/hardware/s812l-s822l/specs.html
[4] 'IBM Power 795 server'
    http://www-03.ibm.com/systems/power/hardware/795/perfdata.html

Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>

svn path=/dists/sid/linux/; revision=21422
2014-06-12 20:01:13 +00:00