Remove unused idle_timestamp field from 32-bit.
Signed-off-by: Brian Gerst <[email protected]>
---
arch/x86/include/asm/hardirq.h | 42 ++++++++++++++++++++++++++++++++----
arch/x86/include/asm/hardirq_32.h | 33 -----------------------------
arch/x86/include/asm/hardirq_64.h | 39 ----------------------------------
3 files changed, 37 insertions(+), 77 deletions(-)
delete mode 100644 arch/x86/include/asm/hardirq_32.h
delete mode 100644 arch/x86/include/asm/hardirq_64.h
diff --git a/arch/x86/include/asm/hardirq.h b/arch/x86/include/asm/hardirq.h
index 000787d..4f77393 100644
--- a/arch/x86/include/asm/hardirq.h
+++ b/arch/x86/include/asm/hardirq.h
@@ -1,11 +1,43 @@
-#ifdef CONFIG_X86_32
-# include "hardirq_32.h"
-#else
-# include "hardirq_64.h"
-#endif
+#ifndef _ASM_X86_HARDIRQ_H
+#define _ASM_X86_HARDIRQ_H
+
+#include <linux/threads.h>
+#include <linux/irq.h>
+
+typedef struct {
+ unsigned int __softirq_pending;
+ unsigned int __nmi_count; /* arch dependent */
+ unsigned int apic_timer_irqs; /* arch dependent */
+ unsigned int irq0_irqs;
+ unsigned int irq_resched_count;
+ unsigned int irq_call_count;
+ unsigned int irq_tlb_count;
+ unsigned int irq_thermal_count;
+ unsigned int irq_spurious_count;
+ unsigned int irq_threshold_count;
+} ____cacheline_aligned irq_cpustat_t;
+
+DECLARE_PER_CPU(irq_cpustat_t, irq_stat);
+
+/* We can have at most NR_VECTORS irqs routed to a cpu at a time */
+#define MAX_HARDIRQS_PER_CPU NR_VECTORS
+
+#define __ARCH_IRQ_STAT
+
+#define inc_irq_stat(member) percpu_add(irq_stat.member, 1)
+
+#define __ARCH_SET_SOFTIRQ_PENDING 1
+
+#define local_softirq_pending() percpu_read(irq_stat.__softirq_pending)
+#define set_softirq_pending(x) percpu_write(irq_stat.__softirq_pending, (x))
+#define or_softirq_pending(x) percpu_or(irq_stat.__softirq_pending, (x))
+
+extern void ack_bad_irq(unsigned int irq);
extern u64 arch_irq_stat_cpu(unsigned int cpu);
#define arch_irq_stat_cpu arch_irq_stat_cpu
extern u64 arch_irq_stat(void);
#define arch_irq_stat arch_irq_stat
+
+#endif /* _ASM_X86_HARDIRQ_H */
diff --git a/arch/x86/include/asm/hardirq_32.h b/arch/x86/include/asm/hardirq_32.h
deleted file mode 100644
index d4b5d73..0000000
--- a/arch/x86/include/asm/hardirq_32.h
+++ /dev/null
@@ -1,33 +0,0 @@
-#ifndef _ASM_X86_HARDIRQ_32_H
-#define _ASM_X86_HARDIRQ_32_H
-
-#include <linux/threads.h>
-#include <linux/irq.h>
-
-typedef struct {
- unsigned int __softirq_pending;
- unsigned long idle_timestamp;
- unsigned int __nmi_count; /* arch dependent */
- unsigned int apic_timer_irqs; /* arch dependent */
- unsigned int irq0_irqs;
- unsigned int irq_resched_count;
- unsigned int irq_call_count;
- unsigned int irq_tlb_count;
- unsigned int irq_thermal_count;
- unsigned int irq_spurious_count;
-} ____cacheline_aligned irq_cpustat_t;
-
-DECLARE_PER_CPU(irq_cpustat_t, irq_stat);
-
-/* We can have at most NR_VECTORS irqs routed to a cpu at a time */
-#define MAX_HARDIRQS_PER_CPU NR_VECTORS
-
-#define __ARCH_IRQ_STAT
-#define __IRQ_STAT(cpu, member) (per_cpu(irq_stat, cpu).member)
-
-#define inc_irq_stat(member) (__get_cpu_var(irq_stat).member++)
-
-void ack_bad_irq(unsigned int irq);
-#include <linux/irq_cpustat.h>
-
-#endif /* _ASM_X86_HARDIRQ_32_H */
diff --git a/arch/x86/include/asm/hardirq_64.h b/arch/x86/include/asm/hardirq_64.h
deleted file mode 100644
index a65bab2..0000000
--- a/arch/x86/include/asm/hardirq_64.h
+++ /dev/null
@@ -1,39 +0,0 @@
-#ifndef _ASM_X86_HARDIRQ_64_H
-#define _ASM_X86_HARDIRQ_64_H
-
-#include <linux/threads.h>
-#include <linux/irq.h>
-#include <asm/apic.h>
-
-typedef struct {
- unsigned int __softirq_pending;
- unsigned int __nmi_count; /* arch dependent */
- unsigned int apic_timer_irqs; /* arch dependent */
- unsigned int irq0_irqs;
- unsigned int irq_resched_count;
- unsigned int irq_call_count;
- unsigned int irq_tlb_count;
- unsigned int irq_thermal_count;
- unsigned int irq_spurious_count;
- unsigned int irq_threshold_count;
-} ____cacheline_aligned irq_cpustat_t;
-
-DECLARE_PER_CPU(irq_cpustat_t, irq_stat);
-
-/* We can have at most NR_VECTORS irqs routed to a cpu at a time */
-#define MAX_HARDIRQS_PER_CPU NR_VECTORS
-
-#define __ARCH_IRQ_STAT 1
-
-#define inc_irq_stat(member) percpu_add(irq_stat.member, 1)
-
-#define local_softirq_pending() percpu_read(irq_stat.__softirq_pending)
-
-#define __ARCH_SET_SOFTIRQ_PENDING 1
-
-#define set_softirq_pending(x) percpu_write(irq_stat.__softirq_pending, (x))
-#define or_softirq_pending(x) percpu_or(irq_stat.__softirq_pending, (x))
-
-extern void ack_bad_irq(unsigned int irq);
-
-#endif /* _ASM_X86_HARDIRQ_64_H */
--
1.6.1
Brian Gerst wrote:
> Remove unused idle_timestamp field from 32-bit.
Dropped. X86_32 doesn't build. X86_64 UP doesn't build. Please at
least do compile testing on all four combinations before sending the
patches.
Thanks.
--
tejun
Tejun Heo wrote:
> Brian Gerst wrote:
>> Remove unused idle_timestamp field from 32-bit.
>
> Dropped. X86_32 doesn't build. X86_64 UP doesn't build. Please at
> least do compile testing on all four combinations before sending the
> patches.
One more thing, can you please split the patch into two such that the
merging and renaming happen as separate steps so that git can tell
that a file has been renamed instead of oh two of those disappeared
and this one popped up? It's a bit tedious but makes log tracking
much easier.
Thanks.
--
tejun
* Tejun Heo <[email protected]> wrote:
> Brian Gerst wrote:
> > Remove unused idle_timestamp field from 32-bit.
>
> Dropped. X86_32 doesn't build. X86_64 UP doesn't build. Please at
> least do compile testing on all four combinations before sending the
> patches.
While this patch was indeed broken, generally for -tip patches we are very
permissive and do not require testing 4 .config variants: compile testing
on the bit width x86 variant that is being modified is enough. If both
variant are modified (as in this case) then compiling the 32-bit and
64-bit defconfig is enough.
If some build failure slips through it will be handled by automated
testing facilities (such as -tip's testing) - it really does not scale if
we expect developers to build kernels they dont use (and dont care about
nearly as much as about their primary config).
This lowers the bar of entry to developers who submit their patches from
low-powered hardware and simply dont have the means to do wide build
testing. The many .config variations are not really the developer's fault
but our collective fault. Developers should spend their time thinking
about patches, not waiting for the nth kernel build to finish.
Ingo
* Tejun Heo <[email protected]> wrote:
> Tejun Heo wrote:
> > Brian Gerst wrote:
> >> Remove unused idle_timestamp field from 32-bit.
> >
> > Dropped. X86_32 doesn't build. X86_64 UP doesn't build. Please at
> > least do compile testing on all four combinations before sending the
> > patches.
>
> One more thing, can you please split the patch into two such that the
> merging and renaming happen as separate steps so that git can tell that
> a file has been renamed instead of oh two of those disappeared and this
> one popped up? It's a bit tedious but makes log tracking much easier.
yes, we do that for all unification patches - the 'large patch' must
always be a simple "git mv", with nothing modified inbetween. That way
it's reviewable and debuggable as well.
Ingo
Hello, Ingo.
Ingo Molnar wrote:
> While this patch was indeed broken, generally for -tip patches we are very
> permissive and do not require testing 4 .config variants: compile testing
> on the bit width x86 variant that is being modified is enough. If both
> variant are modified (as in this case) then compiling the 32-bit and
> 64-bit defconfig is enough.
>
> If some build failure slips through it will be handled by automated
> testing facilities (such as -tip's testing) - it really does not scale if
> we expect developers to build kernels they dont use (and dont care about
> nearly as much as about their primary config).
>
> This lowers the bar of entry to developers who submit their patches from
> low-powered hardware and simply dont have the means to do wide build
> testing. The many .config variations are not really the developer's fault
> but our collective fault. Developers should spend their time thinking
> about patches, not waiting for the nth kernel build to finish.
I just sent a patch with a lot of compile breakages so I'm feeling
quite embarrassed here but when the patch is touching this low in arch
code, I don't think small four configuration build isn't too much
before sending out a patchset. With two quad core machines and ram
disk configured, it just doesn't take that much of time (which BTW
doesn't cost that much these days). With my typical test config,
whole build takes about 80 to 90 seconds. Four times that is still
under ten minutes.
Anyways, it's a balancing act. Four small builds don't sound like too
much to me. Hey, if you're okay with it. :-)
Thanks.
--
tejun
Tejun Heo schrieb:
> [...] but when the patch is touching this low in arch
> code, I don't think small four configuration build isn't too much
> before sending out a patchset. With two quad core machines and ram
> disk configured, it just doesn't take that much of time (which BTW
> doesn't cost that much these days). With my typical test config,
> whole build takes about 80 to 90 seconds. Four times that is still
> under ten minutes.
Wow. Do want. :-)
SCNR
T.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)