Searched hist:90 (Results 126 - 150 of 186) sorted by relevance
/freebsd-10-stable/sys/netinet6/ | ||
H A D | route6.c | diff 181803 Sun Aug 17 21:43:42 MDT 2008 bz Commit step 1 of the vimage project, (network stack) virtualization work done by Marko Zec (zec@). This is the first in a series of commits over the course of the next few weeks. Mark all uses of global variables to be virtualized with a V_ prefix. Use macros to map them back to their global names for now, so this is a NOP change only. We hope to have caught at least 85-90% of what is needed so we do not invalidate a lot of outstanding patches again. Obtained from: //depot/projects/vimage-commit2/... Reviewed by: brooks, des, ed, mav, julian, jamie, kris, rwatson, zec, ... (various people I forgot, different versions) md5 (with a bit of help) Sponsored by: NLnet Foundation, The FreeBSD Foundation X-MFC after: never V_Commit_Message_Reviewed_By: more people than the patch |
/freebsd-10-stable/sys/sparc64/pci/ | ||
H A D | ofw_pci_if.m | diff 115417 Fri May 30 18:48:05 MDT 2003 tmm Fix interrupt assignment for non-builtin PCI devices on e450s. This machine uses a non-standard scheme to specify the interrupts to be assigned for devices in PCI slots; instead of giving the INO or full interrupt number (which is done for the other devices in this box), the firmware interrupt properties contain intpin numbers, which have to be swizzled as usual on PCI-PCI bridges; however, the PCI host bridge nodes have no interrupt map, so we need to guess the correct INO by slot number of the device or the closest PCI-PCI bridge leading to it, and the intpin. To do this, this fix makes the following changes: - Add a newbus method for sparc64 PCI host bridges to guess the INO, and glue code in ofw_pci_orb_callback() to invoke it based on a new quirk entry. The guessing is only done for interrupt numbers too low to contain any IGN found on e450s. - Create another new quirk entry was created to prevent mapping of EBus interrupts at PCI level; the e450 has full INOs in the interrupt properties of EBus devices, so trying to remap them could cause problems. - Set both quirk entries for e450s; remove the no-swizzle entry. - Determine the psycho half (bus A or B) a driver instance manages in psycho_attach() - Implement the new guessing method for psycho, using the slot number, psycho half and property value (intpin). Thanks go to the testers, especially Brian Denehy, who tested many kernels for me until I had found the right workaround. Tested by: Brian Denehy <B.Denehy@90east.com>, jake, fenner, Marius Strobl <marius@alchemy.franken.de>, Marian Dobre <mari@onix.ro> Approved by: re (scottl) |
H A D | ofw_pci.h | diff 115417 Fri May 30 18:48:05 MDT 2003 tmm Fix interrupt assignment for non-builtin PCI devices on e450s. This machine uses a non-standard scheme to specify the interrupts to be assigned for devices in PCI slots; instead of giving the INO or full interrupt number (which is done for the other devices in this box), the firmware interrupt properties contain intpin numbers, which have to be swizzled as usual on PCI-PCI bridges; however, the PCI host bridge nodes have no interrupt map, so we need to guess the correct INO by slot number of the device or the closest PCI-PCI bridge leading to it, and the intpin. To do this, this fix makes the following changes: - Add a newbus method for sparc64 PCI host bridges to guess the INO, and glue code in ofw_pci_orb_callback() to invoke it based on a new quirk entry. The guessing is only done for interrupt numbers too low to contain any IGN found on e450s. - Create another new quirk entry was created to prevent mapping of EBus interrupts at PCI level; the e450 has full INOs in the interrupt properties of EBus devices, so trying to remap them could cause problems. - Set both quirk entries for e450s; remove the no-swizzle entry. - Determine the psycho half (bus A or B) a driver instance manages in psycho_attach() - Implement the new guessing method for psycho, using the slot number, psycho half and property value (intpin). Thanks go to the testers, especially Brian Denehy, who tested many kernels for me until I had found the right workaround. Tested by: Brian Denehy <B.Denehy@90east.com>, jake, fenner, Marius Strobl <marius@alchemy.franken.de>, Marian Dobre <mari@onix.ro> Approved by: re (scottl) |
/freebsd-10-stable/sys/x86/x86/ | ||
H A D | dump_machdep.c | diff 181803 Sun Aug 17 21:43:42 MDT 2008 bz Commit step 1 of the vimage project, (network stack) virtualization work done by Marko Zec (zec@). This is the first in a series of commits over the course of the next few weeks. Mark all uses of global variables to be virtualized with a V_ prefix. Use macros to map them back to their global names for now, so this is a NOP change only. We hope to have caught at least 85-90% of what is needed so we do not invalidate a lot of outstanding patches again. Obtained from: //depot/projects/vimage-commit2/... Reviewed by: brooks, des, ed, mav, julian, jamie, kris, rwatson, zec, ... (various people I forgot, different versions) md5 (with a bit of help) Sponsored by: NLnet Foundation, The FreeBSD Foundation X-MFC after: never V_Commit_Message_Reviewed_By: more people than the patch |
/freebsd-10-stable/usr.sbin/lpr/common_source/ | ||
H A D | displayq.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
H A D | lp.h | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
H A D | rmjob.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
H A D | common.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
/freebsd-10-stable/usr.sbin/lpr/lpc/ | ||
H A D | lpc.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
H A D | cmds.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
/freebsd-10-stable/usr.sbin/lpr/lpd/ | ||
H A D | recvjob.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
H A D | lpd.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
/freebsd-10-stable/lib/msun/ld128/ | ||
H A D | e_rem_pio2l.h | diff 176640 Thu Feb 28 14:22:36 MST 2008 bde Fix and improve some magic numbers for the "medium size" case. e_rem_pio2.c: This case goes up to about 2**20pi/2, but the comment about it said that it goes up to about 2**19pi/2. It went too far above 2**pi/2, giving a multiplier fn with 21 significant bits in some cases. This would be harmful except for a numerical accident. It happens that the terms of the approximation to pi/2, when rounded to 33 bits so that multiplications by 20-bit fn's are exact, happen to be rounded to 32 bits so multiplications by 21-bit fn's are exact too, so the bug only complicates the error analysis (we might lose a bit of accuracy but have bits to spare). e_rem_pio2f.c: The bogus comment in e_rem_pio2.c was copied and the code was changed to be bug-for-bug compatible with it, except the limit was made 90 ulps smaller than necessary. The approximation to pi/2 was not modified except for discarding some of it. The same rough error analysis that justifies the limit of 2**20pi/2 for double precision only justifies a limit of 2**18pi/2 for float precision. We depended on exhaustive testing to check the magic numbers for float precision. More exaustive testing shows that we can go up to 2**28pi/2 using a 53+25 bit approximation to pi/2 for float precision, with a the maximum error for cosf() and sinf() unchanged at 0.5009 ulps despite the maximum error in rem_pio2f being ~0.25 ulps. Implement this. |
/freebsd-10-stable/lib/msun/ld80/ | ||
H A D | e_rem_pio2l.h | diff 176640 Thu Feb 28 14:22:36 MST 2008 bde Fix and improve some magic numbers for the "medium size" case. e_rem_pio2.c: This case goes up to about 2**20pi/2, but the comment about it said that it goes up to about 2**19pi/2. It went too far above 2**pi/2, giving a multiplier fn with 21 significant bits in some cases. This would be harmful except for a numerical accident. It happens that the terms of the approximation to pi/2, when rounded to 33 bits so that multiplications by 20-bit fn's are exact, happen to be rounded to 32 bits so multiplications by 21-bit fn's are exact too, so the bug only complicates the error analysis (we might lose a bit of accuracy but have bits to spare). e_rem_pio2f.c: The bogus comment in e_rem_pio2.c was copied and the code was changed to be bug-for-bug compatible with it, except the limit was made 90 ulps smaller than necessary. The approximation to pi/2 was not modified except for discarding some of it. The same rough error analysis that justifies the limit of 2**20pi/2 for double precision only justifies a limit of 2**18pi/2 for float precision. We depended on exhaustive testing to check the magic numbers for float precision. More exaustive testing shows that we can go up to 2**28pi/2 using a 53+25 bit approximation to pi/2 for float precision, with a the maximum error for cosf() and sinf() unchanged at 0.5009 ulps despite the maximum error in rem_pio2f being ~0.25 ulps. Implement this. |
/freebsd-10-stable/lib/msun/src/ | ||
H A D | e_rem_pio2.c | diff 176640 Thu Feb 28 14:22:36 MST 2008 bde Fix and improve some magic numbers for the "medium size" case. e_rem_pio2.c: This case goes up to about 2**20pi/2, but the comment about it said that it goes up to about 2**19pi/2. It went too far above 2**pi/2, giving a multiplier fn with 21 significant bits in some cases. This would be harmful except for a numerical accident. It happens that the terms of the approximation to pi/2, when rounded to 33 bits so that multiplications by 20-bit fn's are exact, happen to be rounded to 32 bits so multiplications by 21-bit fn's are exact too, so the bug only complicates the error analysis (we might lose a bit of accuracy but have bits to spare). e_rem_pio2f.c: The bogus comment in e_rem_pio2.c was copied and the code was changed to be bug-for-bug compatible with it, except the limit was made 90 ulps smaller than necessary. The approximation to pi/2 was not modified except for discarding some of it. The same rough error analysis that justifies the limit of 2**20pi/2 for double precision only justifies a limit of 2**18pi/2 for float precision. We depended on exhaustive testing to check the magic numbers for float precision. More exaustive testing shows that we can go up to 2**28pi/2 using a 53+25 bit approximation to pi/2 for float precision, with a the maximum error for cosf() and sinf() unchanged at 0.5009 ulps despite the maximum error in rem_pio2f being ~0.25 ulps. Implement this. |
H A D | k_tanf.c | diff 151963 Wed Nov 02 04:45:21 MST 2005 bde Removed dead code for handling tan[f]() on odd multiples of pi/2. This case never occurs since pi/2 is irrational so no multiple of it can be represented as a float and we have precise arg reduction so we never end up with a remainder of 0 in the "kernel" function unless the original arg is 0. If this case occurs, then we would now fall through to general code that returns +-Inf (depending on the sign of the reduced arg) instead of forcing +Inf. The correct handling would be to return NaN since we would have lost so much precision that the correct result can be anything _except_ +-Inf. Don't reindent the else clause left over from this, although it was already bogusly indented ("if (foo) return; else ..." just marches the indentation to the right), since it will be removed too. Index: k_tan.c =================================================================== RCS file: /home/ncvs/src/lib/msun/src/k_tan.c,v retrieving revision 1.10 diff -r1.10 k_tan.c 88,90c88 < if (((ix | low) | (iy + 1)) == 0) < return one / fabs(x); < else { --- > { |
/freebsd-10-stable/share/man/man4/ | ||
H A D | pcm.4 | diff 122741 Sat Nov 15 04:08:57 MST 2003 trhodes Bring in a 90% rewrite of the pcm.4 manual page. This adds tunables, loader options, information on VCHANs, and more. Based on content submitted by: Mathew Kanner <mat@cnd.mcgill.ca> && Cameron Grant Update requested by: ru, and I think hmp |
/freebsd-10-stable/sys/net/ | ||
H A D | if_mib.c | diff 181803 Sun Aug 17 21:43:42 MDT 2008 bz Commit step 1 of the vimage project, (network stack) virtualization work done by Marko Zec (zec@). This is the first in a series of commits over the course of the next few weeks. Mark all uses of global variables to be virtualized with a V_ prefix. Use macros to map them back to their global names for now, so this is a NOP change only. We hope to have caught at least 85-90% of what is needed so we do not invalidate a lot of outstanding patches again. Obtained from: //depot/projects/vimage-commit2/... Reviewed by: brooks, des, ed, mav, julian, jamie, kris, rwatson, zec, ... (various people I forgot, different versions) md5 (with a bit of help) Sponsored by: NLnet Foundation, The FreeBSD Foundation X-MFC after: never V_Commit_Message_Reviewed_By: more people than the patch |
/freebsd-10-stable/sys/netgraph/ | ||
H A D | ng_bridge.c | diff 181803 Sun Aug 17 21:43:42 MDT 2008 bz Commit step 1 of the vimage project, (network stack) virtualization work done by Marko Zec (zec@). This is the first in a series of commits over the course of the next few weeks. Mark all uses of global variables to be virtualized with a V_ prefix. Use macros to map them back to their global names for now, so this is a NOP change only. We hope to have caught at least 85-90% of what is needed so we do not invalidate a lot of outstanding patches again. Obtained from: //depot/projects/vimage-commit2/... Reviewed by: brooks, des, ed, mav, julian, jamie, kris, rwatson, zec, ... (various people I forgot, different versions) md5 (with a bit of help) Sponsored by: NLnet Foundation, The FreeBSD Foundation X-MFC after: never V_Commit_Message_Reviewed_By: more people than the patch |
/freebsd-10-stable/sys/nfs/ | ||
H A D | nfs_diskless.c | diff 181803 Sun Aug 17 21:43:42 MDT 2008 bz Commit step 1 of the vimage project, (network stack) virtualization work done by Marko Zec (zec@). This is the first in a series of commits over the course of the next few weeks. Mark all uses of global variables to be virtualized with a V_ prefix. Use macros to map them back to their global names for now, so this is a NOP change only. We hope to have caught at least 85-90% of what is needed so we do not invalidate a lot of outstanding patches again. Obtained from: //depot/projects/vimage-commit2/... Reviewed by: brooks, des, ed, mav, julian, jamie, kris, rwatson, zec, ... (various people I forgot, different versions) md5 (with a bit of help) Sponsored by: NLnet Foundation, The FreeBSD Foundation X-MFC after: never V_Commit_Message_Reviewed_By: more people than the patch |
/freebsd-10-stable/usr.sbin/lpr/lpr/ | ||
H A D | lpr.c | diff 78146 Tue Jun 12 14:38:20 MDT 2001 gad Fix about 90-100 warnings one gets when trying to compile lpr&friends with BDECFLAGS on, mainly by adding 'const' to parameters in a number of routine declarations. While I'm at it, ANSI-fy all of the routine declarations. The resulting object code is exactly the same after this update as before it, with the exception of one unavoidable change to lpd.o on freebsd/alpha. Also added $FreeBSD$ line to lpc/extern.h lpc/lpc.h lptest/lptest.c Reviewed by: /sbin/md5, and no feedback from freebsd-audit |
/freebsd-10-stable/sys/dev/ofw/ | ||
H A D | ofwbus.c | |
/freebsd-10-stable/sys/netpfil/pf/ | ||
H A D | pf_if.c | |
/freebsd-10-stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ | ||
H A D | dmu_tx.c | diff 307292 Fri Oct 14 01:44:00 MDT 2016 mav MFC r305340: MFC r305337: 7004 dmu_tx_hold_zap() does dnode_hold() 7x on same object Using a benchmark which has 32 threads creating 2 million files in the same directory, on a machine with 16 CPU cores, I observed poor performance. I noticed that dmu_tx_hold_zap() was using about 30% of all CPU, and doing dnode_hold() 7 times on the same object (the ZAP object that is being held). dmu_tx_hold_zap() keeps a hold on the dnode_t the entire time it is running, in dmu_tx_hold_t:txh_dnode, so it would be nice to use the dnode_t that we already have in hand, rather than repeatedly calling dnode_hold(). To do this, we need to pass the dnode_t down through all the intermediate calls that dmu_tx_hold_zap() makes, making these routines take the dnode_t* rather than an objset_t* and a uint64_t object number. In particular, the following routines will need to have analogous *_by_dnode() variants created: dmu_buf_hold_noread() dmu_buf_hold() zap_lookup() zap_lookup_norm() zap_count_write() zap_lockdir() zap_count_write() This can improve performance on the benchmark described above by 100%, from 30,000 file creations per second to 60,000. (This improvement is on top of that provided by working around the object allocation issue. Peak performance of ~90,000 creations per second was observed with 8 CPUs; adding CPUs past that decreased performance due to lock contention.) The CPU used by dmu_tx_hold_zap() was reduced by 88%, from 340 CPU-seconds to 40 CPU-seconds. Sponsored by: Intel Corp. Closes #109 Reviewed by: Steve Gonczi <steve.gonczi@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Ned Bass <bass6@llnl.gov> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Author: Matthew Ahrens <mahrens@delphix.com> openzfs/openzfs@d3e523d489a169ab36f9ec1b2a111a60a5563a9f |
H A D | zap_micro.c | diff 307292 Fri Oct 14 01:44:00 MDT 2016 mav MFC r305340: MFC r305337: 7004 dmu_tx_hold_zap() does dnode_hold() 7x on same object Using a benchmark which has 32 threads creating 2 million files in the same directory, on a machine with 16 CPU cores, I observed poor performance. I noticed that dmu_tx_hold_zap() was using about 30% of all CPU, and doing dnode_hold() 7 times on the same object (the ZAP object that is being held). dmu_tx_hold_zap() keeps a hold on the dnode_t the entire time it is running, in dmu_tx_hold_t:txh_dnode, so it would be nice to use the dnode_t that we already have in hand, rather than repeatedly calling dnode_hold(). To do this, we need to pass the dnode_t down through all the intermediate calls that dmu_tx_hold_zap() makes, making these routines take the dnode_t* rather than an objset_t* and a uint64_t object number. In particular, the following routines will need to have analogous *_by_dnode() variants created: dmu_buf_hold_noread() dmu_buf_hold() zap_lookup() zap_lookup_norm() zap_count_write() zap_lockdir() zap_count_write() This can improve performance on the benchmark described above by 100%, from 30,000 file creations per second to 60,000. (This improvement is on top of that provided by working around the object allocation issue. Peak performance of ~90,000 creations per second was observed with 8 CPUs; adding CPUs past that decreased performance due to lock contention.) The CPU used by dmu_tx_hold_zap() was reduced by 88%, from 340 CPU-seconds to 40 CPU-seconds. Sponsored by: Intel Corp. Closes #109 Reviewed by: Steve Gonczi <steve.gonczi@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com> Reviewed by: Ned Bass <bass6@llnl.gov> Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov> Author: Matthew Ahrens <mahrens@delphix.com> openzfs/openzfs@d3e523d489a169ab36f9ec1b2a111a60a5563a9f |
Completed in 352 milliseconds