On Thursday 02 May 2002 21:19, William Lee Irwin III wrote:
>> Absolutely; I'd be very supportive of improvements for this case as well.
>> Many of the systems with the need for discontiguous memory support will
>> also benefit from parallelizations or other methods of avoiding references
>> to remote nodes/zones or iterations over all nodes/zones.
On Thu, May 02, 2002 at 09:27:00PM +0200, Daniel Phillips wrote:
> Which loop in which function are we talking about?
I believe it's just for_each_zone() and for_each_pgdat(), and their
usage in general. I brewed them up to keep things clean (and by and
large they produced largely equivalent code to what preceded it), but
there's no harm in conditionally defining them. I think it's even
beneficial, since things can use them without concerning themselves
about "will this be inefficient for the common case of UP single-node
x86?" and might also have the potential to remove some other #ifdefs.
In the more general case, avoiding an O(fragments) (or sometimes even
O(mem)) iteration in favor of, say, O(lg(fragments)) or O(cpus)
iteration when fragments is very large would be an excellent optimization.
Andrea, if the definitions of these helpers start getting large, I think
it would help to move them to a separate header. akpm has already done so
with page->flags manipulations in 2.5, and it seems like it wouldn't
do any harm to do something similar in 2.4 either. Does that sound good?
Cheers,
Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/