Messages in this thread | | | Date | Mon, 13 Dec 2004 12:47:37 +0100 | From | Andrea Arcangeli <> | Subject | Re: dynamic-hz |
| |
On Mon, Dec 13, 2004 at 03:25:21AM -0800, Andrew Morton wrote: > We still have 1000-odd places which do things like > > schedule_timeout(HZ/10); > > which will now involve a runtime divide. The propagation of msleep() and > ssleep() will reduce that a bit, but not much.
The above is by far the least cpu-hungry piece, it's going to sleep for 100msec, so any order-of-nanoseconds computation in such path will be by defininition not measurable.
msleep and ssleep as well will obviously be non measurable for the same reason (their only point is to wait and "waste" cpu). I mean, msleep/ssleep are the only places in the kernel that we don't really need to optimize ;).
Most other fast paths can't execute the division or multiplication at compile time anyway, so they'd only save 1 cacheline (at the expense of a bit larger icache).
> It's so simple to turn all those into compile-time divides that we may as > well do it.
I'm not against leaving a compile time option, it's absolutely trivial to add it, but I just don't think it'll provide any measurable benefit in practice, while the ability to switch HZ provides tantible benefits (even to be able to set HZ to higher frequencies than 1khz, so that people can post a nanosleep call that will return in 0.1msec instead of 1msec).
Perhaps __HZ could hurt a bit on a NUMA box where the icache may be spread on the local nodes and the __HZ not, but then the __HZ could be made a __per_cpu variable conditionally to NUMA and they would get dynamic settable hz too, which I believe is significant for a numa box since if they're doing just userspace computing they don't need a fast HZ and they can get back 1% of their cpu power from every cpu in the system (on a 512-way system that's quite a lot more than what you will ever get back from HZ set at compile time ;). - 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/
| |