Messages in this thread | | | Date | Thu, 08 Apr 2004 01:02:49 +1000 | From | Nick Piggin <> | Subject | Re: [Patch 17/23] mask v2 = [6/7] nodemask_t_ia64_changes |
| |
Paul Jackson wrote: > Nick wrote: > >>No, the schedule() fastpath doesn't use find_next_bit. > > > Ok - makes sense - thanks. > > Uninlining it is perhaps the easiest way out. > > That or replacing it with the trivial version that is several times > smaller (loops one bit at a time, checking 'test_bit()'). > > Right now, I don't see any excuse for that fat version of find_next_bit() > to exist. >
Well it would be nice to keep it fast though, especially for big masks like those 64 byte cpumasks of yours. In the scheduler for example, a lot of balancing operations are done with very sparse cpumasks, which your bit at a time version doesn't handle very well.
For example, a global CPU balancing operation on a 512 CPU system with 2 CPUs per node currently does 256 for_each_cpu loops over cpumasks with two entries in them. 130 thousand test_bit loop iteratinos.
The uninlined larger version would have to be smaller and faster than your small version inlined, wouldn't it? - 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/
| |