mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
To: Andi Kleen <ak@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] i386 !NUMA node_to_cpumask broken in early boot
Date: Thu, 18 Aug 2005 21:27:40 -0600 (MDT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0508182116510.28588@montezuma.fsmlabs.com> (raw)
In-Reply-To: <20050819030615.GH22993@wotan.suse.de>

On Fri, 19 Aug 2005, Andi Kleen wrote:

> > Thanks for the feedback, ugly indeed, i was really trying to avoid adding 
> > a new API function or extra cpu_* variables. Ok, here is an 
> > early_node_to_cpumask instead.
> 
> Thinking about it again it's most likely broken with CPU hotplug anyways
> whatever you're doing. So how does your code handle adding new 
> CPUs?  If it does can the normal CPU bootup be handled in the 
> same way. Then this wouldn't be needed at all.

The code is populating IDTs before APs are online, so for a given set of 
processors i would want to install new IDT entries like so;

node_set_intr_gate()
{
	cpumask_t mask = node_to_cpumask(node);
	for_each_cpu_mask(cpu, mask)
		set_intr_gate(per_cpu_ptr(cpu_idt_table, cpu)....
	....
}

Which before resulted in only setting the IDT entry for the BSP.

During boot, i prepare all processor IDTs so they are always 
ready for processors coming online and should take care of hotplug cpu 
too. The only problem with normal bootup is that the node_to_cpumask is
unreliable.

	Zwane


      reply	other threads:[~2005-08-19  3:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-19  2:07 Zwane Mwaikambo
2005-08-19  2:12 ` Andi Kleen
2005-08-19  2:49   ` Zwane Mwaikambo
2005-08-19  3:06     ` Andi Kleen
2005-08-19  3:27       ` Zwane Mwaikambo [this message]

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=Pine.LNX.4.61.0508182116510.28588@montezuma.fsmlabs.com \
    --to=zwane@arm.linux.org.uk \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®