Re: E10000 available for development (trying to)
On Thu, 26 Feb 2004 14:37:32 -0500
Ben Collins <bcollins@debian.org> wrote:
> Only thing I can see about it is that the complete struct being passed
> is in the high 4Megs of the image, and that the function is in the low 4
> Megs. Sounds like something Dave would have to figure out, since it
> likely deals with how the TLB's for the kernel are handled.
The place where the migration thread completion queues are is actually
in the runqueues. These are declared per-cpu objects via the declaration
in kernel/sched.c which looks like:
static DEFINE_PER_CPU(struct runqueue, runqueues);
How this works is, bootmem is allocated for all the per-cpu objects in
the entire kernel image, so something like "sizeof(all_percpu_objects)
* NUM_POSSIBLE_CPUS". There is one "base instance" of the object declared
in the kernel image, and that is used as a template for each per-cpu copy.
Ie. the one is copied into each of the per-cpu instances. This is the
initializer, sorta speak.
All of this work is done in init/main.c:setup_per_cpu_areas().
You might want to have a look at where the symbol range
__per_cpu_start[] --> __per_cpu_end[] falls in these larger images.
For the per-cpu runqueue objects, I don't think the initializer matters.
Because sched_init() sets up all of this stuff I believe. Right, it loops
'i' over NR_CPUS and for each it initializes "cpu_rq(i)". Where it starts
the migration thread for cpu X, you could dump out the runqueue contents for
that CPU to make sure it looks non-bogus.
BTW Ben, I'm still very suspicious about whether elftoaout is doing the
right thing with kernels build using current tools. There are some program
headers that it is simply ignoring, and that may not be kosher. It is
something to address, regardless of this E10K issue.
Reply to: