Impact: clean up

it seems Ingo revert it wrongly.
put it back again

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/include/asm/apicdef.h |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

Index: linux-2.6/arch/x86/include/asm/apicdef.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/apicdef.h
+++ linux-2.6/arch/x86/include/asm/apicdef.h
@@ -132,12 +132,7 @@
 #define APIC_BASE_MSR	0x800
 #define X2APIC_ENABLE	(1UL << 10)
 
-#ifdef CONFIG_X86_32
-# define MAX_IO_APICS 64
-#else
-# define MAX_IO_APICS 128
-# define MAX_LOCAL_APIC 32768
-#endif
+#include <asm/apicnum.h>
 
 /*
  * All x86-64 systems are xAPIC compatible.
--

[ message continues ]

do you mean you submitted the patch and i didnt apply it or had to revert 
it? It never touched upstream so it must have been reverted due to some 
build failure or similar thing.

	Ingo
--

[ message continues ]

like:

In file included from /home/mingo/tip/arch/x86/include/asm/i387.h:16,
                 from 
/home/mingo/tip/arch/x86/include/asm/suspend_32.h:10,
                 from /home/mingo/tip/arch/x86/include/asm/suspend.h:2,
                 from include/linux/suspend.h:5,
                 from arch/x86/kernel/asm-offsets_32.c:11,
                 from arch/x86/kernel/asm-offsets.c:2:
include/linux/hardirq.h:41:27: error:  ':' without preceding '?'
In file included from arch/x86/kernel/asm-offsets_32.c:24,
                 from arch/x86/kernel/asm-offsets.c:2:
include/linux/lguest.h:60:1: error: unterminated argument list invoking 
macro "BITS_TO_LONGS"
In file included from arch/x86/kernel/asm-offsets_32.c:25,
                 from arch/x86/kernel/asm-offsets.c:2:
arch/x86/kernel/../../../drivers/lguest/lg.h:236:1: error: unterminated 
argument list invoking macro "BITS_TO_LONGS"

so i've reverted it again. config attached.

	Ingo
[ message continues ]

(Below are the two commits that i reverted - please reuse the improved 
changelogs when resubmitting it.)

	Ingo

----------->
From af95e2305842d3192ab782abb8ceedc1a2b82d39 Mon Sep 17 00:00:00 2001
From: Yinghai Lu <yinghai@kernel.org>
Date: Sun, 11 Jan 2009 21:42:13 -0800
Subject: [PATCH] x86: include apicnum.h in acpidef.h

Impact: clean up

MAX_IO_APICS and MAX_LOCAL_APIC is already defined in apicnum.h, no
need to duplicate it in apicdef.h.

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/include/asm/apicdef.h |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/apicdef.h b/arch/x86/include/asm/apicdef.h
index 63134e3..85b50a0 100644
--- a/arch/x86/include/asm/apicdef.h
+++ b/arch/x86/include/asm/apicdef.h
@@ -132,12 +132,7 @@
 #define APIC_BASE_MSR	0x800
 #define X2APIC_ENABLE	(1UL << 10)
 
-#ifdef CONFIG_X86_32
-# define MAX_IO_APICS 64
-#else
-# define MAX_IO_APICS 128
-# define MAX_LOCAL_APIC 32768
-#endif
+#include <asm/apicnum.h>
 
 /*
  * All x86-64 systems are xAPIC compatible.

From adf320a657d774d8bdf58b8ffc81670238824c9c Mon Sep 17 00:00:00 2001
From: Yinghai Lu <yinghai@kernel.org>
Date: Sun, 11 Jan 2009 21:43:49 -0800
Subject: [PATCH] x86: use nr_cpus in max_nr_irqs()

Impact: save RAM with large NR_CPUS, get smaller nr_irqs

Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Mike Travis <travis@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/include/asm/irq_vectors.h |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/irq_vectors.h b/arch/x86/include/asm/irq_vectors.h
index 602361a..5b285ca 100644
--- a/arch/x86/include/asm/irq_vectors.h
+++ b/arch/x86/include/asm/irq_vectors.h
@@ -117,8 +117,8 @@
 
 /* defined as a macro so nr_irqs = max_nr_irqs(nr_cpu_ids) can be used */
 # define max_nr_irqs(nr_cpus)				\
-	((8 * nr_cpus) > (32 * MAX_IO_APICS) ...
[ message continues ]

Impact: save RAM with large NR_CPUS, get smaller nr_irqs

Signed-off-by: Yinghai Lu <yinghai@kernel.org>

---
 arch/x86/include/asm/irq_vectors.h |    7 ++-----
 arch/x86/kernel/io_apic.c          |   16 ++++++++++++++++
 include/linux/interrupt.h          |    1 +
 kernel/irq/handle.c                |    9 ++-------
 kernel/softirq.c                   |    5 +++++
 5 files changed, 26 insertions(+), 12 deletions(-)

Index: linux-2.6/arch/x86/include/asm/irq_vectors.h
===================================================================
--- linux-2.6.orig/arch/x86/include/asm/irq_vectors.h
+++ linux-2.6/arch/x86/include/asm/irq_vectors.h
@@ -120,14 +120,11 @@
 # endif
 #else
 
-/* defined as a macro so nr_irqs = max_nr_irqs(nr_cpu_ids) can be used */
-# define max_nr_irqs(nr_cpus)				\
-	((8 * nr_cpus) > (32 * MAX_IO_APICS) ?		\
+# define NR_IRQS					\
+	((8 * NR_CPUS) > (32 * MAX_IO_APICS) ?		\
 		(NR_VECTORS + (8 * NR_CPUS)) :		\
 		(NR_VECTORS + (32 * MAX_IO_APICS)))	\
 
-# define NR_IRQS max_nr_irqs(NR_CPUS)
-
 #endif
 
 #elif defined(CONFIG_X86_VOYAGER)
Index: linux-2.6/arch/x86/kernel/io_apic.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/io_apic.c
+++ linux-2.6/arch/x86/kernel/io_apic.c
@@ -3851,6 +3851,22 @@ void __init probe_nr_irqs_gsi(void)
 		nr_irqs_gsi = nr;
 }
 
+#ifdef CONFIG_SPARSE_IRQ
+int __init arch_probe_nr_irqs(void)
+{
+	int nr;
+
+	nr = ((8 * nr_cpu_ids) > (32 * nr_ioapics) ?
+		(NR_VECTORS + (8 * nr_cpu_ids)) :
+		(NR_VECTORS + (32 * nr_ioapics)));
+
+	if (nr < nr_irqs && nr > nr_irqs_gsi)
+		nr_irqs = nr;
+
+	return 0;
+}
+#endif
+
 /* --------------------------------------------------------------------------
                           ACPI-based IOAPIC Configuration
    -------------------------------------------------------------------------- */
Index: linux-2.6/include/linux/interrupt.h
===================================================================
--- ...
[ message continues ]

Built and tested on an 8-core intel system.  Great reduction
in NR_IRQS:

	[    0.000000] NR_IRQS:33024 nr_irqs:320

Thanks Yinghai!

Ingo - shall I push this one as well?  (If not, then you
can add my:

	Acked-by: Mike Travis <travis@sgi.com>

Thanks,

--

[ message continues ]

yes, please pick it up and i can pull it from you. Please also add a 
longer changelog about the precise effects and perhaps some estimations 
about what the before and after situation is, and perhaps also some bits 
about how it affects normal Linux users as well.

	Ingo
--

[ message continues ]

Hi Ingo,

Just so I don't screw this thing up, exactly what am I to 'pull' to fix
this error (listed at the end of this command sequence)?

Thanks,
Mike

    mkdir linux-2.6-cpus4096-for-ingo
    cd linux-2.6-cpus4096-for-ingo
    git-init-db
    git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
    git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
    git-remote add my-cpus4096 git://git.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git
    git-remote add push-cpus4096 ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git
    git-config --add remote.push-cpus4096.skipDefaultUpdate true
    git-remote update

    git-checkout -b edit-commits my-cpus4096/master
    git-log             # insure the commit is the last one
    git commit --amend

<edit changelog>

    git-push push-cpus4096 edit-commits:master

travis@master.kernel.org's password:
To ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git
 ! [rejected]        edit-commits -> master (non-fast forward)
error: failed to push some refs to 'ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git'

    git-push -f push-cpus4096 edit-commits:master

travis@master.kernel.org's password:
Counting objects: 31, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (16/16), 1.97 KiB, done.
Total 16 (delta 14), reused 12 (delta 11)
error: denying non-fast forward refs/heads/master (you should pull first)
To ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git
 ! [remote rejected] edit-commits -> master (non-fast forward)
error: failed to push some refs to 'ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo.git'

=============================================================
Here is the altered commit message:

commit ...
[ message continues ]

hm, why do you do all this? You should just create a -git based repo on 
kernel.org:

  cd /pub/scm/linux/kernel/git/travis/
  rm -rf linux-2.6-cpus4096-for-ingo
  git-clone --bare --shared ../torvalds/linux-2.6.git linux-2.6-cpus4096-for-ingo

that's all - you dont ever have to touch the master.kernel.org bits on 
that box anymore. Then you can clone it (via ssh) to your local box:

  git clone ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo

that's it - you are all set!

Now you can go into your repo, and do a few convenience things like:

     git-remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
     git-remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git

     git remote update

But these dont ever go to your master.kernel.org tree. Your local 'master' 
branch is what you will push out most of the time.

To prepare a tree for me, if you want to base it on the latest 
tip/cpus4096, you do this:

     git checkout master
     git reset --hard tip/cpus4096

that's all. You can then (force-)push this out to your kernel.org repo 
via:

     git push -f origin master

and you can manipulate your master branch and push it out to your 
master.kernel.org repo whenever you want to.

If you want a separate 'release' branch, you can do it too:

   git checkout master

   [ prepare your master branch with the bits. ]

   git checkout -b for-ingo
   git push origin for-ingo

   [ git checkout master ]

That's it. If the for-ingo branch already exists and you know that it 
contains no bits that i might pull in parallel with you updating it, you 
can force-push it as well:

   git checkout for-ingo
   git reset --hard master          # set it to your release bits
   git push -f origin for-ingo

that's it really.

	Ingo
--

[ message continues ]

Very cool, thanks!!

The one thing I always get hung up on is what args to use with the git
rebase -i command.  Say I want to edit 4a046d1 (which I do ;-), I see
it in my repo with git-log (3rd one down):

commit e46d517...
Merge: a4a0acf... 4a046d1...
Author: Ingo Molnar <mingo@elte.hu>

    Merge branch 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/travis/linux-2.6-cpus4096-for-ingo into cpus4096

commit a4a0acf...
Author: Suresh Siddha <suresh.b.siddha@intel.com>

    x86: fix broken flush_tlb_others_ipi()

commit 4a046d1...
Author: Yinghai Lu <yinghai@kernel.org>

    x86: arch_probe_nr_irqs

commit e65e49d...
Author: Mike Travis <travis@sgi.com>

    irq: update all arches for new irq_desc


Nothing to do

Attempting other args proved equally fruitless.

Thanks,
Mike

Ingo Molnar wrote:

--

[ message continues ]

You shouldnt edit 4a046d1 anymore as i already pulled it - you can queue 
up a fix commit. (Or we can decide to drop the whole tree and re-pull 
yours - but that is an emergency path not to be taken lightly.)

Btw., to 'edit' your own commits, you can always do something like this. 
For example, if this is the current lineup of your own commits (not yet 
pulled by anyone):

 a4a0acf: x86: fix broken flush_tlb_others_ipi()
 28e0886: xen: fix too early kmalloc call
 92296c6: cpumask, irq: non-x86 build failures
 542d865: kstat: modify kstat_irqs_legacy to be variable sized
 9332fcc: irq: initialize nr_irqs based on nr_cpu_ids
 0fa0ebb: irq: allocate irq_desc_ptrs array based on nr_irqs
 e2f4d06: irq: use WARN() instead of WARN_ON().

... and you realize that there's a bug in the middle, at 542d865, that 
you'd like to fix locally before pushing it out for others to pull.

In this case you can rebase and fix in "two phases". The first phase is to 
'reorder commits':

  git rebase -i 542d865^1

i.e. you start your rebase _from before_ the commit in question. All old 
history will be preserved (which is always good - you always want the 
minimum rebase - avoid full rebases as much as possible).

You will be offered this git-rebase screen:

 pick 542d865 kstat: modify kstat_irqs_legacy to be variable sized
 pick 92296c6 cpumask, irq: non-x86 build failures
 pick 28e0886 xen: fix too early kmalloc call
 pick a4a0acf x86: fix broken flush_tlb_others_ipi()

Edit it to move the first line to the last, like this:

 pick 92296c6 cpumask, irq: non-x86 build failures
 pick 28e0886 xen: fix too early kmalloc call
 pick a4a0acf x86: fix broken flush_tlb_others_ipi()
 pick 542d865 kstat: modify kstat_irqs_legacy to be variable sized

and run the rebase. Now you'll have a new lineup with the buggy commit at 
the end. (lets assume there were no conflicts caused by the reordering) 
For example you could get:

 b304542: kstat: modify kstat_irqs_legacy to be variable sized
 ...
[ message continues ]

This all started because you wanted a more descriptive changelog for Yinghai's
probe_nr_irqs() patch.  I was attempting to do this, and is why I sent the
full text to you, in case I couldn't do it (as you explained above).

I'm guessing this subject is now closed?

Thanks,
Mike
--

[ message continues ]

yeah - unless we are forced to do a full rebase or something like that.

	Ingo
--

[ message continues ]

Hi Yinghai,

Actually, Ingo got it right.  I had introduced the apicnum.h file to
get around header entanglements.  But as Ingo pointed out, I did the
include file chain wrong, so removing the apicnum.h file seemed to be
the correct thing to do.  (I just haven't figured out yet how to remove
a file via email patch.  I was just going to clean it up next time I
pushed changes to Ingo.)

Thanks,
Mike


--

[ message continues ]