On Fri, 16 Nov 2007 05:12:21 +0100 Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Eric Dumazet a écrit : > > Arjan van de Ven a écrit : > >> On Thu, 15 Nov 2007 04:01:48 GMT > >> Linux Kernel Mailing List <linux-kernel@vger.kernel.org> wrote: > >> > >>> Gitweb: > >>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 > >>> > >>> > >>> Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent: > >>> 66ba886254edbbd9442d30f1eef6f6fb0145027d Author: Eric Dumazet > >>> <[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 16:14:05 2007 -0800 > >>> Committer: David S. Miller <[EMAIL PROTECTED]> > >>> CommitDate: Wed Nov 14 16:14:05 2007 -0800 > >>> > >>> [NET]: rt_check_expire() can take a long time, add a > >>> cond_resched() On commit > >>> 39c90ece7565f5c47110c2fa77409d7a9478bd5b: > >> > >>> When the IP route cache is big, rt_check_expire() can take a > >>> long time to run. (default settings : 20% of the hash table is > >>> scanned at each invocation) > >>> Adding cond_resched() helps giving cpu to higher priority > >>> tasks if > >>> necessary. > >>> Using a "if (need_resched())" test before calling > >>> "cond_resched();" is necessary to avoid spending too much time > >>> doing the resched check. > >> > >> int __sched cond_resched(void) > >> { > >> if (need_resched() && ..... > >> > >> somehow I wonder why the second if() is useful at all; it's another > >> spot for a branch predictor to miss... and a void function call is > >> really really cheap... > > > > Its not that cheap. The ChangeLog included my own numbers, on a > > Pentium M machine. (i686, 1.6 GHz, 1.5 GB ram) > > > > Without "if (need_resched())" (so calling need_resched() X.XXX.XXX > > times), each run takes 88ms > > > > With the extra check (and *much* less function calls), each run > > takes 25ms > > > > Looking at cond_resched(), I think the extra cost comes from > "mov %esp,%edx ; and $0xffffe000,%edx" (current_thread_info()) > > I dont have oprofile numbers yet, but I suspect CPU may have some > delays to compute this pointer value, since %esp is probably 'busy' > because of the preceding "call" yeah the explicit reference makes the stack pointer tracking engine do a commit I suspect which then also creates a data dependency in the code flow. however... this is likely a good argument for making cond_resched() as a whole a #define (or inline) that does this test and then calls the out of line code (which then doesn't need to retest, so it avoids the double test)... -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - 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/