LATENCYTOP not building on ia64

Hi all,

After da48d094ce5d ("Kconfig: remove HAVE_LATENCYTOP_SUPPORT"), CONFIG_LATENCYTOP can be selected on all architectures. Unfortunately, viro reported that this breaks the build for ia64:

arch/ia64/kernel/entry.S: Assembler messages:
arch/ia64/kernel/entry.S:621: Error: Operand 2 of adds' should be a 14-bit integer (-8192-8191) arch/ia64/kernel/entry.S:728: Error: Operand 2 of adds' should be a 14-bit integer (-8192-8191) arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191) make[1]: *** [arch/ia64/kernel/entry.o] Error 1

This is because the task_struct is over 8K thanks to the latency_record array, which means that the 14-bit immediate offset expected by the adds instruction to grab hold of the thread info flags is now out-of-range on ia64. I had a quick go at fixing it in entry.S, but I ended up with worse code due to the need to perform the offset calculation as a separate step (which introduces a hazard).

We could simply revert da48d094ce5d to make the problem disappear, but I'd be interested to know whether or not this is an ia64-specific problem and therefore whether LATENCYTOP should be opt-out as opposed to opt-in for a given architecture.

Prior to da48d094ce5d, arc, arm, metag, microblaze, parisc, powerpc, s390, sh, sparc, unicore32 and x86 all selected HAVE_LATENCYTOP_SUPPORT so assumedly they don't run into problems. arm64 also works ok with the option enabled.

Will

--->8

index ecb9e75614bf..9c66339e3879 100644
@@ -1600,6 +1600,7 @@ config LATENCYTOP
 	depends on DEBUG_KERNEL
 	depends on STACKTRACE_SUPPORT
 	depends on PROC_FS
+	depends on !IA64
 	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
 	select KALLSYMS
 	select KALLSYMS_ALL