Part of the confusion may lie in the fact that CONFIG_TRANSPARENT_HUGEPAGE
triggers "select COMPACTION" in the Kconfig.

But in any case we don't set TRANSPARENT_HUGEPAGE in the config files either.

It certainly would be better if chromeos/config reflected all the final settings, at least for the default case.

We have some boards that have transparent_hugepage use flag disabled, like
breaglebone, jetstream boards. How can we disable that if we remove this USE flag?

We have notion of flavors to adjust features in configs:

(cr) ((40219cf62301...)) dtor@dtor-ws ~/trunk/src/third_party/kernel/v3.18 $ ls -1 chromeos/config/armel/
chromiumos-armada38x.flavour.config
chromiumos-arm.flavour.config
chromiumos-ipq40xx.flavour.config
common.config

So we have ipq40xx flavor for Google Home (gale) devices, and regular arm flavor for the rest in 3.18. Other kernels are similar. You just need to run "./chromeos/scripts/kernelconfig editconfig" and select needed options for all different flavors. Then splitconfig will bubble up the options as needed.

Beaglebone should simply discard LPAE option when we re-run kernelconfig script as it is guarded by CPU type.

if the USE flag only lives in the kernel eclass, i don't see a strong need to cull it there.  if you want to drop it from board overlays because we default it to on in profiles, then that's fine.

varier@: I would prefer if kernel configuration was mostly contained in <kernel>/chromeos/config/... instead of being spread between those directories and kernel eclass/overlays. We just spent a few hours of several engineers' time working under assumption that we had memory compaction disabled, and researching what would be needed to enable it, whereas it was enabled all along.

I understand that moving everything into <kernel>/chromeos/config/.., is not feasible as different projects use differnt hardware, but core kernel functionality selection should be in kernel splitconfig.

Totally agree with dtor in @8.  Back when transparent_hugepage was an experiment that was enabled in just some boards and not others then it made sense to be a use flag.  Now that it's consistent across all boards of a given class it should be folded into the main kernel config.

I also agree, as I did in #2.

Also I wonder if it wouldn't be useful to have a tool that discovers other settings that may be hidden by the use of "select" in Kconfigs.

I know we can check /build/<board>/boot/config*, but we don't always have that ready.

If you can boot the device, you can always "modprobe configs"

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32

commit e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32
Author: Yunlian Jiang <yunlian@google.com>
Date: Fri May 26 00:15:54 2017

kernel-3_8: enable transparent hugepage for chromeos-intel-pineview.

We want to remove the transparent_hugepage USE flag, so we need
to add this to config file directly.

BUG=chromium:725574
TEST=USE="-transparent_hugepage" emerge-falco chromeos-kernel-3_8
     transparent_hugepage is still enabled.

Change-Id: I1a2e24aeb7913bed3a0c0a71071019364ed5af8a
Reviewed-on: https://chromium-review.googlesource.com/514202
Commit-Ready: Yunlian Jiang <yunlian@chromium.org>
Tested-by: Yunlian Jiang <yunlian@chromium.org>
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>

[modify] https://crrev.com/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32/chromeos/config/i386/common.config
[modify] https://crrev.com/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32/chromeos/config/armel/common.config
[modify] https://crrev.com/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32/chromeos/config/x86_64/chromiumos-x86_64.flavour.config
[modify] https://crrev.com/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32/chromeos/config/base.config
[modify] https://crrev.com/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32/chromeos/config/x86_64/chromeos-intel-pineview.flavour.config
[modify] https://crrev.com/e24bb8bc26b2a1298685f84cdcf41ac19d8f2c32/chromeos/config/x86_64/common.config