[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090302235120.GF27240@localdomain>
Date: Mon, 2 Mar 2009 15:51:20 -0800
From: Ravikiran G Thirumalai <kiran@...lex86.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: Yinghai Lu <yinghai@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
shai@...lex86.org
Subject: Re: [PATCH] x86: don't compile vsmp_64 for 32bit
On Sat, Feb 28, 2009 at 10:44:30AM +0100, Ingo Molnar wrote:
>
>* Ravikiran G Thirumalai <kiran@...lex86.org> wrote:
>
>>
>> True, but by how much? 212 bytes, out of 7285943 bytes which
>> is very very small percentage wise.
>
>How does this eliminate the validity of the patch?
>
It costs 212 bytes to leave is_vsmp_box() to not just be a dummy no-op.
Having is_vsmp_box() detect if the hardware is indeed vSMP, is meaningful even when
CONFIG_VSMP is not turned on. This is because is_vsmp_box() is used to
tell the kernel, that although the cpus being used are supposed to have TSCs
in sync, they are not really in sync. This is because
you cannot ensure TSCs won't drift between multiple boards being aggregated
on vSMP systems. Take the case of distro kernels. Distro kernels typically do
not have CONFIG_X86_VSMP on. Due to the large internode cacheline
setting, CONFIG_VSMP would not be on on the generic distro installer kernels.
If is_vsmp_box() is a no-op, the generic distro installer kernels will
assume TSCs to be synched, which is bad. Hence, it will be nice if, for
the cost of 212 bytes, vsmp64.o be compiled either unconditionally, OR
conditionally for 64bit architectures only. The question is, is 212 bytes out
of 7285943 bytes too expensive for the generic kernels? I hope not.
Thanks,
Kiran
--
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