All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Jaswinder Singh Rajput <jaswinder@kernel.org>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>, x86 maintainers <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -tip] x86: cpu/intel.c cleanup
Date: Sun, 15 Mar 2009 06:55:10 +0100	[thread overview]
Message-ID: <20090315055510.GD20949@elte.hu> (raw)
In-Reply-To: <1237053903.3144.11.camel@localhost.localdomain>


* Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:

> On Sat, 2009-03-14 at 18:04 +0100, Ingo Molnar wrote:
> > * Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> > 
> > > On Sat, 2009-03-14 at 16:31 +0100, Ingo Molnar wrote:
> > > > > 
> > > > > I don't really like this change (last hunk). Doesn't it seem a 
> > > > > bit pointless? It breaks the symmetry with the masked CPUID 
> > > > > levels at the beginning of the function. If somebody wants to 
> > > > > add something else to this function, it might have to be 
> > > > > reindented again. Or is there a problem with too long lines 
> > > > > here?
> > > > 
> > > > yes, it would be cleaner to put the whole family 15 branch into 
> > > > a helper inline function instead.
> > > > 
> > > 
> > > OK, better I keep it unchanged :-)
> > 
> > Why not implement the cleanup i suggested?
> 
> I followed your approached and made new helper function. But the result
> was same, in that helper function I have to check for family 15 and rest
> of things. So I found nothing was gained, So I again reverted it and
> provided you this patch.

Well my suggestion was to:

> > > > yes, it would be cleaner to put the whole family 15 branch into 
> > > > a helper inline function instead.

I.e. replace this branch:

#ifdef CONFIG_KMEMCHECK
	/*
	 * P4s have a "fast strings" feature which causes single-
	 * stepping REP instructions to only generate a #DB on
	 * cache-line boundaries.
	 *
	 * Ingo Molnar reported a Pentium D (model 6) and a Xeon
	 * (model 2) with the same problem.
	 */
	if (c->x86 == 15) {
		u64 misc_enable;

		rdmsrl(MSR_IA32_MISC_ENABLE, misc_enable);

		if (misc_enable & MSR_IA32_MISC_ENABLE_FAST_STRING) {
			printk(KERN_INFO "kmemcheck: Disabling fast string operations\n");

			misc_enable &= ~MSR_IA32_MISC_ENABLE_FAST_STRING;
			wrmsrl(MSR_IA32_MISC_ENABLE, misc_enable);
		}
	}
#endif

With a helper inline function:

	if (c->x86 == 15)
		early_init_intel_fam15();

Why would you have to check family 15 inside 
early_init_intel_fam15() again?

	Ingo

  reply	other threads:[~2009-03-15  5:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-14 12:41 [PATCH -tip] x86: cpu/intel.c cleanup Jaswinder Singh Rajput
2009-03-14 13:11 ` Sam Ravnborg
2009-03-14 13:20   ` Ingo Molnar
2009-03-14 13:37     ` Jaswinder Singh Rajput
2009-03-14 14:00       ` Vegard Nossum
2009-03-14 15:31         ` Ingo Molnar
2009-03-14 16:04           ` Jaswinder Singh Rajput
2009-03-14 17:04             ` Ingo Molnar
2009-03-14 18:05               ` Jaswinder Singh Rajput
2009-03-15  5:55                 ` Ingo Molnar [this message]
2009-03-14 13:21   ` Jaswinder Singh Rajput

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090315055510.GD20949@elte.hu \
    --to=mingo@elte.hu \
    --cc=jaswinder@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=vegard.nossum@gmail.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.