Darren Hart wrote:
First thing that comes to mind, did you look for every place that accesses the
arrays via the rq->lock and make it use the new global array_lock?
Yep. All places where any of "arrays[i]", "expired", or "active" were
accessed are now protected (as far as I can tell) by the new lock.
I'm just wondering if there are any "gotchas" that jump out at people
based on what I'm trying to do, or if it should just be a matter of
changing the data structures and getting the locking right. It's only
when I try to run with multiple cpus that it breaks, so either there's
something wrong in the initialization of the second cpu or else it's a
locking issue.
When I let it use both cpus I get partway through kernel initialization,
then it hangs. Adding instrumentation lets me get further in, which
makes me suspect some kind of race condition.
It would
help if you would post your initial patch for review (designating it as RFC,
not intended for inclusion).
Unfortunately my patch is against a heavily modified version of the
kernel, so I'm not sure how useful it would be. I suppose I could redo
it against a vanilla version of 2.6.10, but that would take some time.
If you think it would be useful I could certainly do it.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]