Hi! > >In the end, Linus will decide this anyway. I can understand that you > >don't want to change your application. Help developing the dynamic > >tick patch, and maybe you won't have to =) > > From what I can tell, tick skipping works fine right now, it just needs > some cleanup. Thus I'd expect something like it will get integrated > into 2.6.14. If it gets in, the default HZ should go back up to 1000. > In that case why decrease it for exactly one patchlevel? > > As an app programmer, it'd be nice not to have to support 2.6.13 > differently from 2.6.(x!=13). For my app, busy waiting means a ~12% > load increase for 2.6.13 compared to (probably) all other 2.6 kernel > versions. That's certainly violating the principle of least surprise. > Up to now, it was easy enough to tell people "upgrade from 2.4.x and > it'll work better". Now it gets more complicated.
BTW I think many architectures have HZ=100 even in 2.6, so it is not as siple as "go 2.6"... Pavel -- teflon -- maybe it is a trademark, but it should not be. - 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/