Messages in this thread | | | Date | Sat, 18 Mar 2006 21:08:40 -0800 | From | Paul Jackson <> | Subject | Re: OOPS: 2.6.16-rc6 cpufreq_conservative |
| |
If find_first_bit and find_next_bit suck so bad, then why just fix their use in the for_each_cpu_mask(). How about the other uses?
Such as the other 50 odd places in the kernel that call them directly, such as:
$ grep ' = find_[a-z]*_bit' lib/bitmap.c rbot = cur = find_first_bit(maskp, nmaskbits); cur = find_next_bit(maskp, nmaskbits, cur+1); i = find_first_bit(buf, bits); i = find_next_bit(buf, bits, i + 1); for (i = find_first_bit(buf, bits); i = find_next_bit(buf, bits, i + 1)) for (oldbit = find_first_bit(src, bits); oldbit = find_next_bit(src, bits, oldbit + 1)) {
Perhaps the common interface to these find_*_bit routines should be out of line, with perhaps just a couple of key calls from the scheduler using the inline form.
And if we fix the cpu loop to the API Linus suggests, we should do the same with the node loops, such as used in:
$ grep for_each.*_node mm/slab.c for_each_node(i) { for_each_node(i) for_each_online_node(i) { for_each_online_node(node) { for_each_online_node(node) { for_each_online_node(node) { for_each_online_node(node) { for_each_online_node(i) { for_each_online_node(i) { for_each_online_node(node) { for_each_online_node(node) { for_each_online_node(node) { for_each_online_node(node) {
And for those of us with too many CPUs, how about something like (totally untested and probably totally bogus):
#if NR_CPUS <= BITS_IN_LONG ... as per Linus, shifting a mask right ... #else #define for_each_cpu_mask(cpu, mask) { for (cpu = 0; cpu < NR_CPUS; cpu++) { if (!(test_bit(cpu, mask)) continue; #endif
#define end_for_each_cpu_mask } }
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - 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/
| |