Re: rtld optimizations
On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. It's really not my place to say, but it seems strange that if an optimization is available people would ignore it because they don't think it's important enough. I don't understand this mentality; if it's not going to break anything and it obviously can improve performance in certain use cases, why not merge it and make FreeBSD even better? Regards, Mark ___ 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: rtld optimizations
On Wed, 26 Jan 2011 09:25:27 -0600 Mark Felder f...@feld.me wrote: On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. It's really not my place to say, but it seems strange that if an optimization is available people would ignore it because they don't think it's important enough. I don't understand this mentality; if it's not going to break anything and it obviously can improve performance in certain use cases, why not merge it and make FreeBSD even better? The link to patch with said optimization is provided and one would hope the next email on this thread provides something more alike to hard numbers proving that it actually helps, instead of mentality discussions. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld optimizations
On Wed, Jan 26, 2011 at 11:02:04AM -0500, Alexander Kabaev wrote: On Wed, 26 Jan 2011 09:25:27 -0600 Mark Felder f...@feld.me wrote: On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: ... numbers proving that it actually helps, instead of mentality Or even slowing things down. Alexander Kabaev - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ 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: rtld optimizations
On Wednesday, January 26, 2011 10:25:27 am Mark Felder wrote: On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. It's really not my place to say, but it seems strange that if an optimization is available people would ignore it because they don't think it's important enough. I don't understand this mentality; if it's not going to break anything and it obviously can improve performance in certain use cases, why not merge it and make FreeBSD even better? Many things that seem obvious aren't actually true, hence the need for actual testing and benchmarks. -- John Baldwin ___ 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: rtld optimizations
On Wed, 26 Jan 2011 11:40:13 -0500 John Baldwin j...@freebsd.org wrote: On Wednesday, January 26, 2011 10:25:27 am Mark Felder wrote: On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. It's really not my place to say, but it seems strange that if an optimization is available people would ignore it because they don't think it's important enough. I don't understand this mentality; if it's not going to break anything and it obviously can improve performance in certain use cases, why not merge it and make FreeBSD even better? Many things that seem obvious aren't actually true, hence the need for actual testing and benchmarks. I can't claim to have rigorously benchmarked this, but I am running with a patched ld-elf.so.1 right now and can state that *subjectively* there is absolutely no difference in the perceived performance. firefox, opera and OpenOffice still seem to be dogs the first time they start up. Since this is all about perception I see no benefit in applying the patch, although it doesn't seem to have broken anything either. -- Gary Jennejohn (gj@) ___ 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: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
Hi, Alex order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). Some good points, but also remember make release also uses cvs grep CVS /usr/src/release/Makefile Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, Not HTML, Not base 64. Reply below text sections not at top, to avoid breaking cumulative context. ___ 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: Why not give git a try? (was Re: [head tinderbox] failure on amd64/amd64)
On Wed, Jan 26, 2011 at 12:00 PM, Julian H. Stacey j...@berklix.com wrote: Hi, Alex order to build the system. the VCS however is not part of the build toolchain however (except 'make update' maybe). Some good points, but also remember make release also uses cvs grep CVS /usr/src/release/Makefile For convenience reasons, just like cdrtools exists purely for utility in release as well. As long as the license doesn't say [if you use our tool,] ur srcs are ours, then I don't see why license matters here. As and long as we package the source with the OS and all of our changes, or provide the ability to install it via a port, we should be ok. clang, llvm, compiler_rt, etc are a different can of worms as the GPLv2 // LGPLv2 is viral and says [if you use our tool with your srcs,] ur srcs have to be open (paraphrased of course), which doesn't work for companies who have proprietary IP. Thanks, -Garrett PS IANAL. ___ 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: heci: a new driver for review and testing
Hi Andriy, On 10/15/09 04:12, Andriy Gapon wrote: Some time ago I posted some ideas about HECI/MEI driver for FreeBSD: http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006 I actually got around to implementing it (in initial/basic form): http://people.freebsd.org/~avg/heci.tgz An old thread I know, but I just noticed my desktop has AMT support and was investigating if I could get access to the Serial Over Lan feature. I stumbled across your HECI driver and thought I'd give it a spin. It loads and attaches fine and unloads without issue as well. I tested with device HECI_DEV_ID_ICH9_82Q35 on a HP DC7800 minitower machine. I get no output when I run your heci-qst program though. Few more details: heci0@pci0:0:3:0: class=0x078000 card=0x2819103c chip=0x29b48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel(R) Management Engine Interface (HECI) (Q35-Chipset)' class = simple comms lstewart@lstewart uname -a FreeBSD lstewart 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0 r217387M: Fri Jan 14 15:52:16 EST 2011 lstewart@lstewart:/usr/obj/usr/src/sys/DESKTOP amd64 Cheers, Lawrence ___ 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
