Re: [RFT][patch] Scheduling for HTT and not only
On 02/15/12 21:54, Jeff Roberson wrote: On Wed, 15 Feb 2012, Alexander Motin wrote: On 02/14/12 00:38, Alexander Motin wrote: I see no much point in committing them sequentially, as they are quite orthogonal. I need to make one decision. I am going on small vacation next week. It will give time for thoughts to settle. May be I indeed just clean previous patch a bit and commit it when I get back. I've spent too much time trying to make these things formal and so far results are not bad, but also not so brilliant as I would like. May be it is indeed time to step back and try some more simple solution. I've decided to stop those cache black magic practices and focus on things that really exist in this world -- SMT and CPU load. I've dropped most of cache related things from the patch and made the rest of things more strict and predictable: http://people.freebsd.org/~mav/sched.htt34.patch This looks great. I think there is value in considering the other approach further but I would like to do this part first. It would be nice to also add priority as a greater influence in the load balancing as well. I have feeling that for timeshare/idle threads balance should take into account not a priority, but a nice level. Priority is very unstable thing that is recalculated each time, while nice it is what really describes how much time thread should get in perspective and those values should be shuffled equally between CPUs. But I haven't thought about specific math yet. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185
> Out of curiosity, where does your code comes from ? The same snippet
> from the `release/8.1.0' branch does not refer to `Giant' at all, it
> only reads:
>
> if (c_lock != NULL) {
> class->lc_lock(c_lock, sharedlock);
Arnaud, I added that code to track down the issue. I was originally
hitting the panic much later after the callout had been executed.
-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185
Hi,
Vijay Singh wrote;
> In the code below:
> (kgdb-amd64-6.8-48) l
> 402 if (c_lock != NULL) {
> 403 if (c_lock ==
> &Giant.lock_object) {
> 404 mtx_lock(&Giant);
> 405 mtx_assert(&Giant,
> MA_OWNED);
> 406 } else {
> 407
> class->lc_lock(c_lock, sharedlock);
> 408 }
>
Out of curiosity, where does your code comes from ? The same snippet
from the `release/8.1.0' branch does not refer to `Giant' at all, it
only reads:
if (c_lock != NULL) {
class->lc_lock(c_lock, sharedlock);
Thanks,
- Arnaud
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Panic in 8.1 in softclock(): mutex Giant not owned at ../../../../sys/kern/kern_mutex.c:185
Hi John,
>> (kgdb-amd64-6.8-71) f 5
>> #5 0x803b73e6 in softclock (arg=0x80c90f40) at
>> ../../../../sys/kern/kern_timeout.c:461
>> 461 class->lc_unlock(c_lock);
>> (kgdb-amd64-6.8-71) l
>> 456 lastfunc = c_func;
>> 457 }
>> 458 #endif
>> 459 CTR1(KTR_CALLOUT, "callout %p
>> finished", c);
>> 460 if ((c_flags & CALLOUT_RETURNUNLOCKED)
>> == 0)
>> 461 class->lc_unlock(c_lock);
>> 462 skip:
>> 463 CC_LOCK(cc);
>> 464 /*
>> 465 * If the current callout is locally
>> (kgdb-amd64-6.8-71) i local
>> c_func = (void (*)(void *)) 0x8060d550
>
> You'll need to see if there is a way that this routine can drop the lock. If
> you can reproduce this panic easily, then perhaps try building with KTR and
> KTR_LOCK traces enabled and use 'show ktr' in ddb to see when this thread
> dropped Giant.
An update. I haven't been able to enable KTR in my environment.
However I found some interesting.
In the code below:
(kgdb-amd64-6.8-48) l
402 if (c_lock != NULL) {
403 if (c_lock ==
&Giant.lock_object) {
404 mtx_lock(&Giant);
405 mtx_assert(&Giant,
MA_OWNED);
406 } else {
407 class->lc_lock(c_lock,
sharedlock);
408 }
I hit the assert in line 405. So right after locking Giant, it is
found unlocked!!!
Everytime this hits, I see that kldload is running on the other CPU:
(kgdb-amd64-6.8-48) show_ps_running
CPU ticks pri thread tid pid
state VSZ RSS cmd
0 2 52 0xff000424c800 1611 TDS_RUNNING
0K0K [intr]
1 3 76 0xff0004618400 1000651481 TDS_RUNNING
3808K 760K kldload
Reporting it here to see if someone has seen this before.
-vijay
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
CUDA porting effort?
Given that NVidia is releasing the CUDA platform source on a limited basis, is anyone actively working to port it to FreeBSD? The reason I ask is that to get access to the source, you have to submit a request explaining what you intend to use it for. It might be a good idea to get ahold of the source on behalf of FreeBSD, so that interested people could work on porting it. I could devote a small amount of time to such an effort; I'm wondering if there's interest from anyone else. signature.asc Description: OpenPGP digital signature
Re: [RFT][patch] Scheduling for HTT and not only
On Wed, 15 Feb 2012, Alexander Motin wrote: On 02/14/12 00:38, Alexander Motin wrote: I see no much point in committing them sequentially, as they are quite orthogonal. I need to make one decision. I am going on small vacation next week. It will give time for thoughts to settle. May be I indeed just clean previous patch a bit and commit it when I get back. I've spent too much time trying to make these things formal and so far results are not bad, but also not so brilliant as I would like. May be it is indeed time to step back and try some more simple solution. I've decided to stop those cache black magic practices and focus on things that really exist in this world -- SMT and CPU load. I've dropped most of cache related things from the patch and made the rest of things more strict and predictable: http://people.freebsd.org/~mav/sched.htt34.patch This looks great. I think there is value in considering the other approach further but I would like to do this part first. It would be nice to also add priority as a greater influence in the load balancing as well. This patch adds check to skip fast previous CPU selection if it's SMT neighbor is in use, not just if no SMT present as in previous patches. I've took affinity/preference algorithm from the first patch and improved it. That makes pickcpu() to prefer previous core or it's neighbors in case of equal load. That is very simple to keep it, but still should give cache hits. I've changed the general algorithm of topology tree processing. First I am looking for idle core on the same last-level cache as before, with affinity to previous core or it's neighbors on higher level caches. Original code could put additional thread on already busy core, while next socket is completely idle. Now if there is no idle core on this cache, then all other CPUs are checked. CPU groups comparison now done in two steps: first, same as before, compared summary load of all cores; but now, if it is equal, I am comparing load of the less/most loaded cores. That should allow to differentiate whether load 2 really means 1+1 or 2+0. In that case group with 2+0 will be taken as more loaded than one with 1+1, making group choice more grounded and predictable. I've added randomization in case if all above factors are equal. This all sounds good. I will need to review in detail but the approach seems straightforward and fixes corner cases that are undesirable. As before I've tested this on Core i7-870 with 4 physical and 8 logical cores and Atom D525 with 2 physical and 4 logical cores. On Core i7 I've got speedup up to 10-15% in super-smack MySQL and PostgreSQL indexed select for 2-8 threads and no penalty in other cases. pbzip2 shows up to 13% performance increase for 2-5 threads and no penalty in other cases. Can you also test buildworld or buildkernel with a -j value twice the number of cores? This is an interesting case because it gets little benefit from from affinity and really wants the best balancing possible. It's also the first thing people will complain about if it slows. Tests on Atom show mostly about the same performance as before in database benchmarks: faster for 1 thread, slower for 2-3 and about the same for other cases. Single stream network performance improved same as for the first patch. That CPU is quite difficult to handle as with mix of effective SMT and lack of L3 cache different scheduling approaches give different results in different situations. Specific performance numbers can be found here: http://people.freebsd.org/~mav/bench.ods Every point there includes at least 5 samples and except pbzip2 test that is quite unstable with previous sources all are statistically valid. Florian is now running alternative set of benchmarks on dual-socket hardware without SMT. Again, thank you very much for working on this. Jeff -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFT][patch] Scheduling for HTT and not only
On 02/15/12 21:54, Jeff Roberson wrote: On Wed, 15 Feb 2012, Alexander Motin wrote: As before I've tested this on Core i7-870 with 4 physical and 8 logical cores and Atom D525 with 2 physical and 4 logical cores. On Core i7 I've got speedup up to 10-15% in super-smack MySQL and PostgreSQL indexed select for 2-8 threads and no penalty in other cases. pbzip2 shows up to 13% performance increase for 2-5 threads and no penalty in other cases. Can you also test buildworld or buildkernel with a -j value twice the number of cores? This is an interesting case because it gets little benefit from from affinity and really wants the best balancing possible. It's also the first thing people will complain about if it slows. I'll do it, but even now I can say that existing balancing algorithm requires improvements to better handle SMT. If I understand correctly, present code never takes the last running thread from it's CPU. It is fine for non-SMT systems, but with SMT it may cause imbalance and as result reduced total performance. While current pickcpu() algorithm should be precise enough, its decision can be easily affected by some microsecond transient load, such as interrupt threads, etc, and results of that decision may be effective for seconds. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nologin size
Haven't checked into it, but quick guess static vs dynamic, stripped vs not stripped, check those first. You have likely compiled dynamic nologin. -Simon On Wed, 15 Feb 2012 14:28:54 -0500, Ansar Mohammed wrote: >Hello all, >I am trying to build a minimal size FreeBSD 9 installation and I >noticed that the size of nologin is almost 200k. >I built FreeBSD from source so I checked the distribution, and it's also 200k. >So I went back to the source and just compiled nologin.c and it came up to 5k. >Can anyone explain why this executable is so large? >___ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nologin size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/15/12 11:28, Ansar Mohammed wrote: > Hello all, I am trying to build a minimal size FreeBSD 9 > installation and I noticed that the size of nologin is almost > 200k. I built FreeBSD from source so I checked the distribution, > and it's also 200k. So I went back to the source and just compiled > nologin.c and it came up to 5k. The Makefile have described why it's statically linked: # It is important that nologin be statically linked for security # reasons. A dynamic non-setuid binary can be linked against a trojan # libc by setting LD_LIBRARY_PATH appropriately. Both sshd(8) and # login(1) make it possible to log in with an unsanitized environment, # rendering a dynamic nologin binary virtually useless. NO_SHARED= YES Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEbBAEBCAAGBQJPPA7RAAoJEG80Jeu8UPuz2k0H8wbyLWS6+V0ebKJzPtB1BZzP o6VWo6sXrG5sMb7kegQdtouYjjfCh1XGxj8jT/nCdOcmXFTvta4GaEnwNZjT3IJp bhIRU3sh7G3AOs9WjXlDhwyPCuLp3LdWPu6/4kjdME3VZp6YQRn6SSHtS/OAG/nS HJtlee64Udlkj1OVIPKENpdSdv4dzJt5afSsK0Ju9HH+vrpFKv5fwUWcXVCFya4R iPiU+hDlVUG0ivjK7Aa12rKavrJxmuC6am7KansLF9LsjTHm8zBxswPgJwVEXO9v xIoFHnbfUHLi9r/NAUICudpPmoNfp8M8MNei+n2KQwPK4FsHdiIGcIkfQCsrJQ== =4yw1 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFT][patch] Scheduling for HTT and not only
On 02/14/12 00:38, Alexander Motin wrote: I see no much point in committing them sequentially, as they are quite orthogonal. I need to make one decision. I am going on small vacation next week. It will give time for thoughts to settle. May be I indeed just clean previous patch a bit and commit it when I get back. I've spent too much time trying to make these things formal and so far results are not bad, but also not so brilliant as I would like. May be it is indeed time to step back and try some more simple solution. I've decided to stop those cache black magic practices and focus on things that really exist in this world -- SMT and CPU load. I've dropped most of cache related things from the patch and made the rest of things more strict and predictable: http://people.freebsd.org/~mav/sched.htt34.patch This patch adds check to skip fast previous CPU selection if it's SMT neighbor is in use, not just if no SMT present as in previous patches. I've took affinity/preference algorithm from the first patch and improved it. That makes pickcpu() to prefer previous core or it's neighbors in case of equal load. That is very simple to keep it, but still should give cache hits. I've changed the general algorithm of topology tree processing. First I am looking for idle core on the same last-level cache as before, with affinity to previous core or it's neighbors on higher level caches. Original code could put additional thread on already busy core, while next socket is completely idle. Now if there is no idle core on this cache, then all other CPUs are checked. CPU groups comparison now done in two steps: first, same as before, compared summary load of all cores; but now, if it is equal, I am comparing load of the less/most loaded cores. That should allow to differentiate whether load 2 really means 1+1 or 2+0. In that case group with 2+0 will be taken as more loaded than one with 1+1, making group choice more grounded and predictable. I've added randomization in case if all above factors are equal. As before I've tested this on Core i7-870 with 4 physical and 8 logical cores and Atom D525 with 2 physical and 4 logical cores. On Core i7 I've got speedup up to 10-15% in super-smack MySQL and PostgreSQL indexed select for 2-8 threads and no penalty in other cases. pbzip2 shows up to 13% performance increase for 2-5 threads and no penalty in other cases. Tests on Atom show mostly about the same performance as before in database benchmarks: faster for 1 thread, slower for 2-3 and about the same for other cases. Single stream network performance improved same as for the first patch. That CPU is quite difficult to handle as with mix of effective SMT and lack of L3 cache different scheduling approaches give different results in different situations. Specific performance numbers can be found here: http://people.freebsd.org/~mav/bench.ods Every point there includes at least 5 samples and except pbzip2 test that is quite unstable with previous sources all are statistically valid. Florian is now running alternative set of benchmarks on dual-socket hardware without SMT. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: nologin size
> -Original Message- > From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd- > hack...@freebsd.org] On Behalf Of Ansar Mohammed > Sent: Wednesday, February 15, 2012 11:29 AM > To: freebsd-hackers@freebsd.org > Subject: nologin size > > Hello all, > I am trying to build a minimal size FreeBSD 9 installation and I > noticed that the size of nologin is almost 200k. > I built FreeBSD from source so I checked the distribution, and it's also 200k. > So I went back to the source and just compiled nologin.c and it came up to 5k. > > Can anyone explain why this executable is so large? Dynamic versus static executable. 200K version: % ldd /usr/sbin/nologin ldd: /usr/sbin/nologin: not a dynamic ELF executable 5K version (produced manually by compiling/linking oneself -- shown below): % cd /usr/src/usr.sbin/nologin % sudo cc -c nologin.c -o nologin.o % sudo cc -g nologin.o -o nologin % ldd nologin nologin: libc.so.7 => /lib/libc.so.7 (0x2809) -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: nologin size
You are right. Fast catch :) On Wed, Feb 15, 2012 at 2:39 PM, Simon wrote: > > Haven't checked into it, but quick guess static vs dynamic, stripped vs not > stripped, > check those first. You have likely compiled dynamic nologin. > > -Simon > > > On Wed, 15 Feb 2012 14:28:54 -0500, Ansar Mohammed wrote: > >>Hello all, >>I am trying to build a minimal size FreeBSD 9 installation and I >>noticed that the size of nologin is almost 200k. >>I built FreeBSD from source so I checked the distribution, and it's also >> 200k. >>So I went back to the source and just compiled nologin.c and it came up to >> 5k. >> >>Can anyone explain why this executable is so large? >>___ >>freebsd-hackers@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" >> > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
nologin size
Hello all, I am trying to build a minimal size FreeBSD 9 installation and I noticed that the size of nologin is almost 200k. I built FreeBSD from source so I checked the distribution, and it's also 200k. So I went back to the source and just compiled nologin.c and it came up to 5k. Can anyone explain why this executable is so large? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Kerberos and FreeBSD
Going back on this topic, it seems that there are alot of things that are being shipped with FreeBSD that I am not sure we need in the base distribution. Does anyone use portalfs? On Fri, Feb 10, 2012 at 3:54 AM, Ansar Mohammed wrote: > Thanks for the feedback. > I built world and disabled Kerberos in src.conf. > > I will just install Heimdal via ports now. > > There seems to be alot of other rather old bits of software in a > default installation. I noticed some old digiboard utility in a base > 9.0 build. > > On Wed, Feb 8, 2012 at 5:41 PM, Rick Macklem wrote: >> Benjamin Kaduk wrote: >>> On Wed, 8 Feb 2012, Ansar Mohammed wrote: >>> >>> > Hello All, >>> > Is the port of Heimdal on FreeBSD being maintained? The version that >>> > ships with 9.0 seems a bit old. >>> > >>> > #> /usr/libexec/kdc-v >>> > kdc (Heimdal 1.1.0) >>> > Copyright 1995-2008 Kungliga Tekniska Högskolan >>> > Send bug-reports to heimdal-b...@h5l.org >>> >>> My understanding is that every five years or so, someone becomes fed >>> up >>> enough with the staleness of the "current" version and puts in the >>> effort >>> to merge in a newer version. >>> It looks like 3 years ago, dfr brought in that Heimdal 1.1 you see, to >>> replace the Heimdal 0.6 that nectar brought in 8 years ago. >>> I don't know of anyone with active plans to bring in a new version, at >>> present. >>> >>> -Ben Kaduk >>> >> I think it's a little trickier than it sounds. The Kerberos in FreeBSD >> isn't vanilla Heimdal 1.1, but a somewhat modified variant. >> >> Heimdal libraries have a separate source file for each function, plus >> a source file that defines all global storage used by functions in the >> library. >> One difference w.r.t. the FreeBSD variant that I am aware of is: >> - Some of the functions were moved from one library to another. (I don't >> know why, but maybe it was to avoid a POLA violation which would require >> apps to be linked with additional libraries?) >> - To do this, some global variables were added to the source file in the >> library these functions were moved to. >> As such, if you statically link an app. to both libraries, the global >> variable >> can come up "multiply defined". (I ran into this when I was developing a >> "gssd" >> prior to the one introduced as part of the kernel rpc.) You can get around >> this >> by dynamically linking, being careful about the order in which the libraries >> are >> specified. (The command "krb5-config --libs" helps w.r.t. this.) >> >> I don't know what else was changed, but I do know that it isn't as trivial as >> replacing the sources with ones from a newer Heimdal release. >> >> I think it would be nice if a newer Heimdal release was brought it, with the >> minimal changes required to make it work. (If that meant that apps. needed >> more >> libraries, the make files could use "krb5-config --libs" to handle it, I >> think?) >> >> Oh, and I'm not volunteering to try and do it;-) rick >> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: backup BIOS settings
I tested it. It really works. Thank You! Łukasz Kurek Dnia 8 lutego 2012 21:13 Andrey Zonov napisał(a): > On 10.01.2012 7:01, Łukasz Kurek wrote: > > Hi, > > Is it possible to backup BIOS settings (CMOS configuration) to file and > > restore this settings on the other machine (the same hardware configuration > > and the same BIOS)? > > > > I try do it for this way: > > > > kldload nvram > > > > dd if=/dev/nvram of=nvram.bin (backup) > > > > dd if=nvram.bin of=/dev/nvram (restore) > > > > > > but this way always load default BIOS settings, not my (probably there is > > some kind of error). > > Try sysutils/nvramtool instead. > > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: memmem small optimalisation
On Tue, Feb 14, 2012 at 07:25:14PM +0100, Bernard van Gastel wrote: > Hi all, > > I was looking through the sources of memmove at [1], and saw a (very) > small optimization opportunity. The 'memcmp' also compares the current > character, but the current character is already checked (first part of > the condition). As we already know the size of the string is greater as > 1 (it is checked before the loop), it is possible to replace the memcmp > with (possible doing the decrease of s_len once outside the loop): > memcpy(&cur[1], &cs[1], s_len-1) You are right, also second argument for memcpy() also can be calculated outside of the loop (remembering first character from this buffer is required). One can find similar optimization in other simple memmem() implementations. (search memmem on http://code.google.com/ for example). > Am I missing something? E.g. is readability more important as speed? > This made me wonder what generally the tradeoff is that has to be taken > into account in these cases? Looks like it will give a little improvement. If one want to use such function for huge data, then more advanced string searching algorithms are required. > [1] > http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/memmem.c?rev=1.2 , > excerpt below: > for (cur = (char *)cl; cur <= last; cur++) > if (cur[0] == cs[0] && memcmp(cur, cs, s_len) == 0) >return cur; ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
memmem small optimalisation
Hi all, I was looking through the sources of memmove at [1], and saw a (very) small optimization opportunity. The 'memcmp' also compares the current character, but the current character is already checked (first part of the condition). As we already know the size of the string is greater as 1 (it is checked before the loop), it is possible to replace the memcmp with (possible doing the decrease of s_len once outside the loop): memcpy(&cur[1], &cs[1], s_len-1) Am I missing something? E.g. is readability more important as speed? This made me wonder what generally the tradeoff is that has to be taken into account in these cases? Regards, Bernard [1] http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/memmem.c?rev=1.2 , excerpt below: for (cur = (char *)cl; cur <= last; cur++) if (cur[0] == cs[0] && memcmp(cur, cs, s_len) == 0) return cur; --- Bernard van Gastel Bit Powder RSS Junkie? Download the app with push notifications for Android: https://market.android.com/details?id=com.bitpowder.rssjunkie
