Re: x86 unaligned access followup.
John Baldwin wrote: Also note that this will play hell with some of the recent copy avoidance changes made by Bill Paul to the ethernet drivers, to avoid the expense of copying the packet, with the knowledge that there would be an increased overhead in the resulting packet field unaligned accesses when decoding IP packets... [ ... ] I didn't say it was a good thing, I was just saying how it was done. :) From Bill's description of the network stuff, it sounds like the unaligned access on x86 is cheaper than the copy that would otherwise be done, so we don't want AC checks in that case anyways. I don't know if I entriely believe that... it depends on how big the average packets are. For a web server, for example, there is the initial request, and then there's ACK's, so the copy overhead is negligible, and might outweigh the unaligned access overhead, particularly if you could delay the copy until it was abosolutely necessary (e.g. avoid copying the 14 byte ethernet header, etc., and do the copy in ip_input() instead). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
[EMAIL PROTECTED] wrote: A shakedown cruise could end up being very rough... you would effectively need to check an unaligned access in kernel is OK flag in many of these instances, and fall back to doing the copy when it was false. ...therefore - never mind. Perhaps some app code may break. ;-) The point was that this code breaks on some architectures supported by FreeBSD anyway, and moving at least some of the pain onto x86 people would end up minimizing that breakage. Right now, being able to make a bug break all architectures equally looks pretty good to people having to keep up with the x86 port of FreeBSD's rate of breakage of others, like the Alpha, when people with just x86 hardware break things without knowing it. Most of the App code is fixed, since most of it runs on the Alpha without a lot of problems, these days. Your biggest problem is bound to be the non-native ABI's, such as what people call the Linux emulator, since x86 programmers on Linux aren't nearly as careful with their code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
On 19-Jul-01 Terry Lambert wrote: [EMAIL PROTECTED] wrote: A shakedown cruise could end up being very rough... you would effectively need to check an unaligned access in kernel is OK flag in many of these instances, and fall back to doing the copy when it was false. ...therefore - never mind. Perhaps some app code may break. ;-) The point was that this code breaks on some architectures supported by FreeBSD anyway, and moving at least some of the pain onto x86 people would end up minimizing that breakage. Right now, being able to make a bug break all architectures equally looks pretty good to people having to keep up with the x86 port of FreeBSD's rate of breakage of others, like the Alpha, when people with just x86 hardware break things without knowing it. It is very rare that the alpha port is broken as you describe. Sometimes a bug will have a different affect on the alpha than on x86, but except for bugs in sys/alpha that x86'ers won't be committing, very few of the bugs break just the alpha and not the x86 as well. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
It is very rare that the alpha port is broken as you describe. Sometimes a bug will have a different affect on the alpha than on x86, but except for bugs in sys/alpha that x86'ers won't be committing, very few of the bugs break just the alpha and not the x86 as well. Generally this is true. Most of the alpha vs. x86 issues are found in compilation. Actually, to be fair, we'd have to consider all the kernel subsystems that have *not* in fact been tested on alpha. The dozens of warnings from NetGraph or CODA code indicate that there might be problems there, for instance. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
Matthew Jacob writes: Actually, to be fair, we'd have to consider all the kernel subsystems that have *not* in fact been tested on alpha. The dozens of warnings from NetGraph or CODA code indicate that there might be problems there, for instance. NetGraph certainly has some 32-bit asssumptions embedded in it that actively break on an Alpha. See kern/27767. -- Sudish Joseph To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
Cool. Thanks. I'll rip it out of modules builds for alpha then- it'll save some time in kernel rebuilds. On 19 Jul 2001, Sudish Joseph wrote: Matthew Jacob writes: Actually, to be fair, we'd have to consider all the kernel subsystems that have *not* in fact been tested on alpha. The dozens of warnings from NetGraph or CODA code indicate that there might be problems there, for instance. NetGraph certainly has some 32-bit asssumptions embedded in it that actively break on an Alpha. See kern/27767. -- Sudish Joseph To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
John Baldwin wrote: Actually, since the 486, it's been possible for us to turn on unaligned access exceptions on the x86. We should probably consider doing this, to ensure better performance, and to avoid the unnecessary bus overhead we eat for unaligned access today... not to mention how it could shake out the drivers. Now *that* is a very cool idea. As Johnny Carson would say I did not know that. How would this be done? I assume it's some bit-flip for the chip? D'ya have a sample bit 'o code for this? It's the AC bit in eflags. Note that this will not trap 64 bit unaligned accesses, only 32. Also note that this will play hell with some of the recent copy avoidance changes made by Bill Paul to the ethernet drivers, to avoid the expense of copying the packet, with the knowledge that there would be an increased overhead in the resulting packet field unaligned accesses when decoding IP packets... A shakedown cruise could end up being very rough... you would effectively need to check an unaligned access in kernel is OK flag in many of these instances, and fall back to doing the copy when it was false. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
On 18-Jul-01 Terry Lambert wrote: John Baldwin wrote: It's the AC bit in eflags. Note that this will not trap 64 bit unaligned accesses, only 32. And only at pl 3... Also note that this will play hell with some of the recent copy avoidance changes made by Bill Paul to the ethernet drivers, to avoid the expense of copying the packet, with the knowledge that there would be an increased overhead in the resulting packet field unaligned accesses when decoding IP packets... A shakedown cruise could end up being very rough... you would effectively need to check an unaligned access in kernel is OK flag in many of these instances, and fall back to doing the copy when it was false. ...therefore - never mind. Perhaps some app code may break. ;-) Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: x86 unaligned access followup.
On 18-Jul-01 Terry Lambert wrote: John Baldwin wrote: Actually, since the 486, it's been possible for us to turn on unaligned access exceptions on the x86. We should probably consider doing this, to ensure better performance, and to avoid the unnecessary bus overhead we eat for unaligned access today... not to mention how it could shake out the drivers. Now *that* is a very cool idea. As Johnny Carson would say I did not know that. How would this be done? I assume it's some bit-flip for the chip? D'ya have a sample bit 'o code for this? It's the AC bit in eflags. Note that this will not trap 64 bit unaligned accesses, only 32. Also note that this will play hell with some of the recent copy avoidance changes made by Bill Paul to the ethernet drivers, to avoid the expense of copying the packet, with the knowledge that there would be an increased overhead in the resulting packet field unaligned accesses when decoding IP packets... A shakedown cruise could end up being very rough... you would effectively need to check an unaligned access in kernel is OK flag in many of these instances, and fall back to doing the copy when it was false. I didn't say it was a good thing, I was just saying how it was done. :) From Bill's description of the network stuff, it sounds like the unaligned access on x86 is cheaper than the copy that would otherwise be done, so we don't want AC checks in that case anyways. -- Terry -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: x86 unaligned access followup.
On 17-Jul-01 Matthew Jacob wrote: Actually, since the 486, it's been possible for us to turn on unaligned access exceptions on the x86. We should probably consider doing this, to ensure better performance, and to avoid the unnecessary bus overhead we eat for unaligned access today... not to mention how it could shake out the drivers. Now *that* is a very cool idea. As Johnny Carson would say I did not know that. How would this be done? I assume it's some bit-flip for the chip? D'ya have a sample bit 'o code for this? It's the AC bit in eflags. -matt -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
