[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48C53E59.9010709@sgi.com>
Date: Mon, 08 Sep 2008 08:01:45 -0700
From: Mike Travis <travis@....com>
To: Ingo Molnar <mingo@...e.hu>
CC: Bert Wesarg <bert.wesarg@...glemail.com>,
Andrew Morton <akpm@...ux-foundation.org>,
davej@...emonkey.org.uk, David Miller <davem@...emloft.net>,
Eric Dumazet <dada1@...mosbay.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Jack Steiner <steiner@....com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
Jes Sorensen <jes@....com>, "H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 11/13] genapic: reduce stack pressuge in io_apic.c step
3 target_cpus
Ingo Molnar wrote:
>>> +#ifdef CONFIG_X86_64
>>> +#define TARGET_CPUS(retval) (genapic->target_cpus)(&(retval))
>>> +#else
>>> +#define TARGET_CPUS(retval) retval = (genapic->target_cpus())
>>> +#endif
>
> hm, this should be unified.
>
> Ingo
As I did that one first, I didn't want to muddle through too much i386 code,
but when I did the vector_allocation_domain, it became more clear that making
them common would be better.
I also tripped myself up because one of my test i386 configs had 64 cpus and
it fired up the "NR_CPUS > BITS_PER_LON" code. ;-) [And I'm supposing it's
probably justified to believe that there may be "fairly large" 32-bit systems,
for those applications that need horsepower but not a lot of memory.]
Thanks,
Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists