Re: Generic crc32c support in kernel?
On Fri, Aug 12, 2016 at 11:30:15PM +0200, Joerg Sonnenberger wrote: > Can we please stop with that bogus myth? The crc32 was only a very small > part of the issue and the real issue, the seeking in the kernel image, > is still not resolved. True, avoiding the seeking would cut down the number of crc32 calculations significantly - but still the time difference is remarkable. Martin
Re: Generic crc32c support in kernel?
On Fri, Aug 12, 2016 at 09:48:44PM +0200, Martin Husemann wrote: > On Fri, Aug 12, 2016 at 12:44:36PM -0700, Alistair Crooks wrote: > > Yeah, a lib would be the best place for this - as well as ext\dfs, iscsi > > and sctp use crc32c, and there will probably be more users. Would also be > > good to get this shared with userland via src/common > > There are space/time trade offs and we might need a special small version > for bootloaders. Innocent changes in this area made booting of compressed > kernels take multiple minutes (instead of a few seconds) on some machines > recently. Can we please stop with that bogus myth? The crc32 was only a very small part of the issue and the real issue, the seeking in the kernel image, is still not resolved. Joerg
Re: Generic crc32c support in kernel?
> On Aug 12, 2016, at 3:48 PM, Martin Husemann wrote: > > On Fri, Aug 12, 2016 at 12:44:36PM -0700, Alistair Crooks wrote: >> Yeah, a lib would be the best place for this - as well as ext\dfs, iscsi >> and sctp use crc32c, and there will probably be more users. Would also be >> good to get this shared with userland via src/common > > There are space/time trade offs and we might need a special small version > for bootloaders. Innocent changes in this area made booting of compressed > kernels take multiple minutes (instead of a few seconds) on some machines > recently. True. A smallest implementation would be a bit at a time (essentially just executing the definition); a good compromise is the VAX one of 4 bits at a time. paul
Re: Generic crc32c support in kernel?
> On Aug 12, 2016, at 3:24 PM, Jaromír Doleček > wrote: > > ... > We do have crc32 support in libkern, so I was thinking doing something along > that. > ... > What is general option, is there any interest to have crc32c support > consolidated into a lib, should I put some efford into making this shared > code? It adds some kernel bloat, so I'm slightly reluctant. It seems sensible. It could be done by a common CRC routine that takes a table pointer argument, then the two specific routines are just wrappers. paul
Re: current amd64 crashes in usb_transfer_complete
Takahiro Hayashi wrote: > Could you try both of > > http://www.netbsd.org/~skrll/usb.softint.diff > https://mail-index.netbsd.org/tech-kern/2016/08/09/msg020963.html > > and check if you can still see the problem? The crash happened only once. I'm not sure that running with these will prove anything. I'll try to take steps to reproduce the crash again before running with these patches. Alex
Re: Generic crc32c support in kernel?
On Fri, Aug 12, 2016 at 12:44:36PM -0700, Alistair Crooks wrote: > Yeah, a lib would be the best place for this - as well as ext\dfs, iscsi > and sctp use crc32c, and there will probably be more users. Would also be > good to get this shared with userland via src/common There are space/time trade offs and we might need a special small version for bootloaders. Innocent changes in this area made booting of compressed kernels take multiple minutes (instead of a few seconds) on some machines recently. Martin
Re: Generic crc32c support in kernel?
Yeah, a lib would be the best place for this - as well as ext\dfs, iscsi and sctp use crc32c, and there will probably be more users. Would also be good to get this shared with userland via src/common On 12 August 2016 at 12:24, Jaromír Doleček wrote: > Hi, > > I'm working on ext2fs code now, ext3/ext4 uses crc32c almost exclusively > to checksum many filesystem structures, so I'll need this soon to write > data properly and thus support generally used filesystem options. > > We do have crc32 support in libkern, so I was thinking doing something > along that. > > I noticed we have something in sctp_crc32.c, also there is another > implementation in iscsi code. I also found FreeBSD has consolidated and > optimized this a bit, they use one shared implementation for both places. > Even there, it's just C code - countrary to Linux, which has also code to > use the Intel CPU instructions if available. So I've been thinking I could > either extract this into some shared code; or just create third fork within > kernel specially for ext2fs. > > What is general option, is there any interest to have crc32c support > consolidated into a lib, should I put some efford into making this shared > code? It adds some kernel bloat, so I'm slightly reluctant. > > Jaromir >
Generic crc32c support in kernel?
Hi, I'm working on ext2fs code now, ext3/ext4 uses crc32c almost exclusively to checksum many filesystem structures, so I'll need this soon to write data properly and thus support generally used filesystem options. We do have crc32 support in libkern, so I was thinking doing something along that. I noticed we have something in sctp_crc32.c, also there is another implementation in iscsi code. I also found FreeBSD has consolidated and optimized this a bit, they use one shared implementation for both places. Even there, it's just C code - countrary to Linux, which has also code to use the Intel CPU instructions if available. So I've been thinking I could either extract this into some shared code; or just create third fork within kernel specially for ext2fs. What is general option, is there any interest to have crc32c support consolidated into a lib, should I put some efford into making this shared code? It adds some kernel bloat, so I'm slightly reluctant. Jaromir
Re: current amd64 crashes in usb_transfer_complete
Could you try both of http://www.netbsd.org/~skrll/usb.softint.diff https://mail-index.netbsd.org/tech-kern/2016/08/09/msg020963.html and check if you can still see the problem? Thanks, -- t-hash
Re: current amd64 crashes in usb_transfer_complete
Could you try both of http://www.netbsd.org/~skrll/usb.softint.diff https://mail-index.netbsd.org/tech-kern/2016/08/09/msg020963.html and check if you can still see the problem? Thanks, -- t-hash
