* Re: [NET]: rt_check_expire() can take a long time, add a cond_resched() [not found] ` <20071115193802.4ec64eef@laptopd505.fenrus.org> @ 2007-11-16 4:07 ` David Miller [not found] ` <473D131A.5000200@cosmosbay.com> 1 sibling, 0 replies; 5+ messages in thread From: David Miller @ 2007-11-16 4:07 UTC (permalink / raw) To: arjan; +Cc: linux-kernel, netdev, dada1 From: Arjan van de Ven <arjan@infradead.org> Date: Thu, 15 Nov 2007 19:38:02 -0800 > On Thu, 15 Nov 2007 04:01:48 GMT > Linux Kernel Mailing List <linux-kernel@vger.kernel.org> wrote: > > > 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... Not by Eric's tests. Please read the thread, he checked and it's 50ms more expensive to make the function call. Please, when you notice something interesting in something flying by on git-web, go check thing out we probably discussed the thing you're interested in. And please at least CC: netdev about networking patches, and also the patch author, which I've corrected in this reply. ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <473D131A.5000200@cosmosbay.com>]
[parent not found: <473D18A5.2090309@cosmosbay.com>]
* Re: [NET]: rt_check_expire() can take a long time, add a cond_resched() [not found] ` <473D18A5.2090309@cosmosbay.com> @ 2007-11-16 5:59 ` Arjan van de Ven 2007-11-17 12:56 ` Andi Kleen 0 siblings, 1 reply; 5+ messages in thread From: Arjan van de Ven @ 2007-11-16 5:59 UTC (permalink / raw) To: Eric Dumazet; +Cc: Linux Kernel Mailing List, davem, netdev On Fri, 16 Nov 2007 05:12:21 +0100 Eric Dumazet <dada1@cosmosbay.com> 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 > >>> <dada1@cosmosbay.com> AuthorDate: Wed Nov 14 16:14:05 2007 -0800 > >>> Committer: David S. Miller <davem@davemloft.net> > >>> 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 arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [NET]: rt_check_expire() can take a long time, add a cond_resched() 2007-11-16 5:59 ` Arjan van de Ven @ 2007-11-17 12:56 ` Andi Kleen 2007-11-17 15:21 ` Herbert Xu 2007-11-18 0:03 ` David Miller 0 siblings, 2 replies; 5+ messages in thread From: Andi Kleen @ 2007-11-17 12:56 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Eric Dumazet, Linux Kernel Mailing List, davem, netdev Arjan van de Ven <arjan@infradead.org> writes: >> > >> > 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 ms?!? The numbers sound wrong. Wrong unit? >> > >> >> 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)... Disadvantage would be that might_sleep would be commonly skipped then (unless you actually need to reschedule) But perhaps that's not a big issue. -Andi ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [NET]: rt_check_expire() can take a long time, add a cond_resched() 2007-11-17 12:56 ` Andi Kleen @ 2007-11-17 15:21 ` Herbert Xu 2007-11-18 0:03 ` David Miller 1 sibling, 0 replies; 5+ messages in thread From: Herbert Xu @ 2007-11-17 15:21 UTC (permalink / raw) To: Andi Kleen; +Cc: arjan, dada1, linux-kernel, davem, netdev, mingo Andi Kleen <andi@firstfloor.org> wrote: > >>> > With the extra check (and *much* less function calls), each run >>> > takes 25ms > > ms?!? The numbers sound wrong. Wrong unit? That's quite possible with a huge routing cache. I think that's the reason Eric is doing this in the first place. >> 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)... > > Disadvantage would be that might_sleep would be commonly skipped then > (unless you actually need to reschedule) > But perhaps that's not a big issue. On a related note, would it be possible for cond_resched() to be compiled out completely if we're doing real preemption as opposed to voluntary preemption? Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [NET]: rt_check_expire() can take a long time, add a cond_resched() 2007-11-17 12:56 ` Andi Kleen 2007-11-17 15:21 ` Herbert Xu @ 2007-11-18 0:03 ` David Miller 1 sibling, 0 replies; 5+ messages in thread From: David Miller @ 2007-11-18 0:03 UTC (permalink / raw) To: andi; +Cc: arjan, dada1, linux-kernel, netdev From: Andi Kleen <andi@firstfloor.org> Date: Sat, 17 Nov 2007 13:56:08 +0100 > Arjan van de Ven <arjan@infradead.org> writes: > >> > > >> > 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 > > ms?!? The numbers sound wrong. Wrong unit? Read what Eric is saying. He is saying "any entire run" purging the routing cache takes that long, not just one call. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-11-18 0:03 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200711150401.lAF41mSs021898@hera.kernel.org>
[not found] ` <20071115193802.4ec64eef@laptopd505.fenrus.org>
2007-11-16 4:07 ` [NET]: rt_check_expire() can take a long time, add a cond_resched() David Miller
[not found] ` <473D131A.5000200@cosmosbay.com>
[not found] ` <473D18A5.2090309@cosmosbay.com>
2007-11-16 5:59 ` Arjan van de Ven
2007-11-17 12:56 ` Andi Kleen
2007-11-17 15:21 ` Herbert Xu
2007-11-18 0:03 ` David Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).