Re: Kpdf and -march=pentium4?
I noticed that while making kdegraphics from ports, if -march=pentium4 is in the compiler flags, I will finally get a non-working kpdf. It compiles fine but when I try to open a pdf file, kdpf will core dupm. But a kpdf compiled without -march=pentium4 will work just fine. For this reason, should we put something in kdegraphics3's Makefile to prevent a bad kdpf? E.g. a patch like this: kdegraphics3 compiled with CPUTYPE=p4, CGLAGS=-Os -pipe -fno-strict-aliasing works fine here. Worked with KDE 3.3.x, and still works with KDE 3.4. I've tested it with small PDFs (2 or 3 pages) and large PDFs (30+ pages), and everything works fine for me. -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: contributing to fbsd
The VM map algorithms are the same as ever, though. They use linear traversal along with a cached reference to the last lookup. There are certainly some workloads that should benefit from this, so it definitely could be something you could work on. Not any more. The first_free hint was replaced by an O(log n) algorithm built into the splay tree back in August 2004. See rev. 1.357 of vm_map.c. --Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kpdf and -march=pentium4?
Well, I had -O2 with -march=pentium4. Maybe that's the reason of different results. On March 26, 2005 10:27 am, Freddie Cash wrote: kdegraphics3 compiled with CPUTYPE=p4, CGLAGS=-Os -pipe -fno-strict-aliasing works fine here. Worked with KDE 3.3.x, and still works with KDE 3.4. I've tested it with small PDFs (2 or 3 pages) and large PDFs (30+ pages), and everything works fine for me. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
On Sat, 19 Mar 2005 13:06:29 +0100 Attila Nagy [EMAIL PROTECTED] wrote: It seems to me that building kernel with icc is currently broken, at least in 5-STABLE. Could somebody investigate this? I don't have a problem to compile it with a recent -current and a recent icc (-stable not tested), but the resulting kernel imediatly panics (page fault in _mtx_...()). Bye, Alexander. -- It's not a bug, it's tradition! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
name cache (was Re[4]: vn_fullpath())
Hi, Sorry for reopening an old thread. I am doing this because last time around I was unaware of some issues. There are more corner cases/issues with vn_fullpath() and possibly the name cache. Please correct me if I am wrong. Perhaps, I would even personally look into fixing these, but I would like to know everyone agrees that this is needed. 1. vn_fullpath() does not return names for VCHR vnodes. I think it would be handy if this was possible. 2. It appears that vn_fullpath() has problems with FD 0..2. [It even seems to happen regardless whether file descriptors were inherited or open via $foo my.file] I am under the impression that Linux d_path() does these things. Is there an agreement that this a problem and it would be benefitial to have vn_fullpath() [and name cache] behave in a proper way? Where does dragonfly stand on this? Thank you, Igor :I seem to recall that DragonFly keeps the intermediate nodes. There's no way to backport that, it would be hundreds of man hours of work. DragonFly uses a totally different namecache topology now, one that is mandatory and which guarentees the existance of intermediate nodes. You'd have to implement something similar to libc's getcwd code. e.g. .. through and scan each directory to find the matching inode if the namecache entry is not present. It actually wouldn't be too hard to do. It wouldn't be efficient, but vn_fullpath() is rarely used so it shouldn't be a problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
On Sun, Mar 27, 2005 at 01:30:59PM +0200, Alexander Leidinger wrote: It seems to me that building kernel with icc is currently broken, at least in 5-STABLE. Could somebody investigate this? I don't have a problem to compile it with a recent -current and a recent icc (-stable not tested), but the resulting kernel imediatly panics (page fault in _mtx_...()). Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: name cache (was Re[4]: vn_fullpath())
On Sun, 27 Mar 2005, Igor Shmukler wrote: Sorry for reopening an old thread. I am doing this because last time around I was unaware of some issues. There are more corner cases/issues with vn_fullpath() and possibly the name cache. Please correct me if I am wrong. Perhaps, I would even personally look into fixing these, but I would like to know everyone agrees that this is needed. 1. vn_fullpath() does not return names for VCHR vnodes. I think it would be handy if this was possible. On FreeBSD, this occurs because devfs doesn't use the name cache. Two easy solutions are: - Use the name cache in devfs. This would have to be done carefully in the context of cloning, etc, but should work out. - Add a VOP/VFS operation to help figure out a pathname with the help of the file system, and implement it for devfs. This would avoid having to deal with cache invalidation issues in devfs. 2. It appears that vn_fullpath() has problems with FD 0..2. [It even seems to happen regardless whether file descriptors were inherited or open via $foo my.file] I'm not familiar with this issue specifically. Normally these descriptors point to tty's (unnamed due to devfs issues above) and pipes (no name), which would generally explain the issues. However, the my.file case is a bit concerning. Could you confirm that the file descriptor in that case is definitely pointed at a vnode? I am under the impression that Linux d_path() does these things. Is there an agreement that this a problem and it would be benefitial to have vn_fullpath() [and name cache] behave in a proper way? Linux does something a little different in how they maintain references to files -- their struct inode is logically equivilent to our struct vnode, in that it's a virtualized inode. However, they have an additional structure named struct dentry, which is a reference counted inode reference, but includes pointers into the name cache and a cached local name. The struct file in Linux references a dentry rather than a pure inode. This means that name information for inodes is usually immediately available to consumers, and the name cache is aware of the use of inodes and paths more explicitly. A dentry is not always present, though, but often will be when there's a process around acting explicitly on a file. Robert N M Watson Where does dragonfly stand on this? Thank you, Igor :I seem to recall that DragonFly keeps the intermediate nodes. There's no way to backport that, it would be hundreds of man hours of work. DragonFly uses a totally different namecache topology now, one that is mandatory and which guarentees the existance of intermediate nodes. You'd have to implement something similar to libc's getcwd code. e.g. .. through and scan each directory to find the matching inode if the namecache entry is not present. It actually wouldn't be too hard to do. It wouldn't be efficient, but vn_fullpath() is rarely used so it shouldn't be a problem. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ICC would provide better low level code (remind: Intel C Compiler. It would mean better performance). rookie ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: name cache (was Re[4]: vn_fullpath())
On FreeBSD, this occurs because devfs doesn't use the name cache. Two easy solutions are: - Use the name cache in devfs. This would have to be done carefully in the context of cloning, etc, but should work out. - Add a VOP/VFS operation to help figure out a pathname with the help of the file system, and implement it for devfs. This would avoid having to deal with cache invalidation issues in devfs. I would prefer whatever would be a lowest impact uniform (for different FSs) solution. I will start looking into this issue. I'm not familiar with this issue specifically. Normally these descriptors point to tty's (unnamed due to devfs issues above) and pipes (no name), which would generally explain the issues. However, the my.file case is a bit concerning. Could you confirm that the file descriptor in that case is definitely pointed at a vnode? I will do this. I would like to point out ( guess I was not clear the first time). That even if std[in/out/err] is VREG, not VCHR after child process inhereted this descriptor vn_fullpath() does not work. I understand that this sounds fishy, because fd simply points to vnode, but that the impression for now. If one closes a standard descriptor then opens a file, it does work, but seems not to survive through inheritance. I will follow-up with more information on this. Maybe, files issue for 0..2 is a just a product of imagination :) Linux does something a little different in how they maintain references to I am aware that Linux dentry/inode/cache are different, but I was asking this for a simple (selfish) reason. If there is a concesus that d_path() like functionality [in a black-box way i.e. let's forget how it is implemented] would be very helpful, then I think if a patch was made it might be committed before 5.5 is out. In that case, I would try to work on this and/or even ask my colleagues to help with coding/testing. If this is viewed as an obscure feature that will not be included anytime soon, I would remove from my agenda for now. I thank you Robert and everyone else who spent time reading this thread and thinking about this whole issue. Thank you, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: relation between PQ_CACHESIZE and PQ_L2_SIZE
--- Igor Shmukler [EMAIL PROTECTED] wrote: http://lists.freebsd.org/mailman/htdig/freebsd-hackers/2003-June/001655.html But what puzzled me is : why not page size is a factor when calculating the number of colors? Page coloring in freebsd was implemented by John Dyson. It is needed to better utilize the cache. Depending on cache's implementation fully-associative vs. 4-way vs 2-way etc you might have problems. A subset of bits (low-bits) from the page frame's (physical) address tells us where can data be stored in processor cache. We want a relatively equal distribution of these colors so that we utilize as much of cache real estate as possible. Hence, we are interested in the size of a set, not size of a page. I am sure, there are whole bunch of articles written about this. I could give you some pointers offline. Igor. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] I have read two papers. Both of them think page size impact the number of colorings. The first one: R.E.Kessler page placement algorithms for large-indexed caches excerpt from this paper , Let N be the cache size in pages and B=N/A(A is associativity) be the number of bins The second paper William L.Lynch The Interaction Of Virtual Memory and Cache Memory excerpt from this paper ,section 5.3 The number of colors depends on the page size. As th page size increases, the number of colors decreases until the page size is equal to the cache size-per-degree-of-associative and I find Alan Cox's post http://lists.freebsd.org/pipermail/freebsd-current/2004-June/028470.html quoted from the post 1. Cache size alone does not correctly determine the number of colors,except for direct map caches. The correct formula is (cache size in bytes / page size in bytes) / degree of cache associativity Thus, the comments would lead one to configure his/her system with too many colors. I think Alan is right . What's you opinion? Thanks! Best Regards! Bao Zhao __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NIC detected, but won't DHCP or configure
Thanks VERY much. The card works just fine now. Andrew - Original Message - From: [EMAIL PROTECTED] (Dag-Erling Smørgrav) Date: Wednesday, March 23, 2005 9:42 am Subject: Re: NIC detected, but won't DHCP or configure Andrew Robinson [EMAIL PROTECTED] writes: re_probe(): vid 10ec did 8169 hwrev 1000 That's an 8169SB, which is supported in -CURRENT. Try the attached patch. I'll try to get it merged before 5.4-RELEASE. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2005 [EMAIL PROTECTED] wrote: Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ICC would provide better low level code (remind: Intel C Compiler. It would mean better performance). rookie If any, still produces not all that much of a difference of code between the newer gcc34 and as much performance differance as your going to get isnt going to even be noticeable in the long run. Your just setting your self up for failure with something that isnt really going to give you the desired effects. - -- Best regards, --c0ldbyte -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F iD8DBQFCRwjgsmFQuvffl58RAoqKAJ44D4TFVVaHgK2bP7rrKV0cLHBGlQCeJauB ajI0mxvPps7e/l9dU14DMMU= =73/q -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2005, c0ldbyte wrote: On Sun, 27 Mar 2005 [EMAIL PROTECTED] wrote: Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ICC would provide better low level code (remind: Intel C Compiler. It would mean better performance). rookie If any, still produces not all that much of a difference of code between the newer gcc34 and as much performance differance as your going to get isnt going to even be noticeable in the long run. Your just setting your self up for failure with something that isnt really going to give you the desired effects. -- Best regards, --c0ldbyte PS: There is coders from Intel that do work on some of the code for gcc34. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (FreeBSD) Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F iD8DBQFCRwlhsmFQuvffl58RAq83AJsGKYklfVtdxeT8UcIcJ21TaqAmiQCfY6Fz JhQgmTHP66gd6ySeo0zueHc= =RrMC -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
c0ldbyte wrote: If any, still produces not all that much of a difference of code between the newer gcc34 and as much performance differance as your going to get isnt going to even be noticeable in the long run. Your just setting your self up for failure with something that isnt really going to give you the desired effects. You don't have to use it, but it is good if you *can*. I guess besides that having a cleaner code base which compiles not only with exactly one compiler it is always good to have the ability to try something else out. BTW, on my humble Pentium II server I noticed significant speedups, compared to the system compiler. But that's purely empirical. -- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU) phone @work: +361 371 3536 ISOs: http://www.fsn.hu/?f=downloadcell.: +3630 306 6758 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
c0ldbyte wrote: PS: There is coders from Intel that do work on some of the code for gcc34. Wow. As far as I know, there are some coders from Nominum who do (or did) work on bind9. And? Bind9 is at least 10 times slower on FreeBSD than Nominum's CNS. :( I didn't get your point. -- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU) phone @work: +361 371 3536 ISOs: http://www.fsn.hu/?f=downloadcell.: +3630 306 6758 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
find -exec {} + fails with -or and ! (bin/79263)
The current implementation of the final (possibly only) execution of
find -exec {} + is incomplete and only works if the -exec is on the top
level of (implicitly) -and'ed primaries, not if it is behind -or or !. I
have a patch for this in PR bin/79263.
Examples (copied from PR):
Simple not-so-practical example (/home/jilles/tmp/find is the patched version
of /usr/src/usr.bin/find):
[EMAIL PROTECTED] /home/jilles/tmp% find find \! -exec echo {} +
(no output)
[EMAIL PROTECTED] /home/jilles/tmp% find/find find \! -exec echo {} +
find find/option.c find/extern.h find/find.1 find/find.c find/find.h
find/function.c find/getdate.y find/ls.c find/main.c find/misc.c
find/operator.c find/Makefile find/find.o find/function.o find/ls.o find/main.o
find/misc.o find/operator.o find/option.o find/getdate.c find/getdate.o
find/find find/find.1.gz
(expected output)
Practical example (searching through a Subversion checkout):
[EMAIL PROTECTED] /home/jilles/src/svn/hyperion% find . \( -name .svn -prune \)
-o -type f -exec grep -i silence /dev/null {} +
(no output)
[EMAIL PROTECTED] /home/jilles/src/svn/hyperion% ~/tmp/find/find . \( -name
.svn -prune \) -o -type f -exec grep -i silence /dev/null {} +
(expected output, snipped here)
In comparison:
[EMAIL PROTECTED] /home/jilles/src/svn/hyperion% find . \( -name .svn -prune \)
-o -type f -print0 | xargs -0 grep -i silence /dev/null
gives the expected output, even without the patch.
--
Jilles Tjoelker
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5-STABLE kernel build with icc broken
On Sun, Mar 27, 2005, c0ldbyte wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 27 Mar 2005 [EMAIL PROTECTED] wrote: Without intending to start any compiler holy wars, what benefits does ICC provide over GCC for the end user? ICC would provide better low level code (remind: Intel C Compiler. It would mean better performance). rookie If any, still produces not all that much of a difference of code between the newer gcc34 and as much performance differance as your going to get isnt going to even be noticeable in the long run. Your just setting your self up for failure with something that isnt really going to give you the desired effects. For some applications, particularly in scientific computing, icc is significantly better. The FreeBSD kernel is not in this category, however. Operating system kernels tend to spend most of their time chasing pointers and copying data, and compilers can't really optimize these operations. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
