From mav at FreeBSD.org Sat Jul 4 19:15:08 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sat Jul 4 19:15:21 2009 Subject: DFLTPHYS vs MAXPHYS Message-ID: <4A4FAA2D.3020409@FreeBSD.org> Hi. Can somebody explain me a difference between DFLTPHYS and MAXPHYS constants? As I understand, the last one is a maximal amount of memory, that can be mapped to the kernel, or passed to the hardware drivers. But why then DFLTPHYS is used in so many places and what does it mean? Isn't it a time to review their values for increasing? 64KB looks funny, comparing to modern memory sizes and data rates. It just increases interrupt rates, but I don't think it really need to be so small to improve interactivity now. -- Alexander Motin From gary.jennejohn at freenet.de Sun Jul 5 08:00:47 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Jul 5 08:00:54 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A4FAA2D.3020409@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> Message-ID: <20090705100044.4053e2f9@ernst.jennejohn.org> On Sat, 04 Jul 2009 22:14:53 +0300 Alexander Motin wrote: > Can somebody explain me a difference between DFLTPHYS and MAXPHYS > constants? As I understand, the last one is a maximal amount of memory, > that can be mapped to the kernel, or passed to the hardware drivers. But > why then DFLTPHYS is used in so many places and what does it mean? > There's a pretty good comment on these in /sys/conf/NOTES. > Isn't it a time to review their values for increasing? 64KB looks funny, > comparing to modern memory sizes and data rates. It just increases > interrupt rates, but I don't think it really need to be so small to > improve interactivity now. > Probably historical from the days when memory was scarce. There's nothing preventing the user from upping these values in his kernel config file. But note the warning in NOTES about possibly making the kernel unbootable. It's not clear whether this warning is still valid given todays larger memory footprints and the inmproved VM system. I wonder whether all drivers can correctly handle larger values for DFLTPHYS. --- Gary Jennejohn From mav at FreeBSD.org Sun Jul 5 08:38:38 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 08:38:44 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <20090705100044.4053e2f9@ernst.jennejohn.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> Message-ID: <4A50667F.7080608@FreeBSD.org> Gary Jennejohn wrote: > On Sat, 04 Jul 2009 22:14:53 +0300 > Alexander Motin wrote: > >> Can somebody explain me a difference between DFLTPHYS and MAXPHYS >> constants? As I understand, the last one is a maximal amount of memory, >> that can be mapped to the kernel, or passed to the hardware drivers. But >> why then DFLTPHYS is used in so many places and what does it mean? > > There's a pretty good comment on these in /sys/conf/NOTES. But it does not explains why. >> Isn't it a time to review their values for increasing? 64KB looks funny, >> comparing to modern memory sizes and data rates. It just increases >> interrupt rates, but I don't think it really need to be so small to >> improve interactivity now. > > Probably historical from the days when memory was scarce. > > There's nothing preventing the user from upping these values in his > kernel config file. But note the warning in NOTES about possibly > making the kernel unbootable. It's not clear whether this warning is > still valid given todays larger memory footprints and the inmproved > VM system. > > I wonder whether all drivers can correctly handle larger values for > DFLTPHYS. There are always will be drivers/devices with limitations. They should just be able to report that limitations to system. This is possible with GEOM, but it doesn't looks tuned well for all providers. There are many places, when DFLTPHYS used just with hope that it will work. IMHO if driver unable to adapt to any defined DFLTPHYS value, it should not use it, but instead should announce some specific value that it really supports. -- Alexander Motin From brde at optusnet.com.au Sun Jul 5 14:11:55 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sun Jul 5 14:12:02 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A50667F.7080608@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> Message-ID: <20090705223126.I42918@delplex.bde.org> On Sun, 5 Jul 2009, Alexander Motin wrote: > Gary Jennejohn wrote: >> On Sat, 04 Jul 2009 22:14:53 +0300 >> Alexander Motin wrote: >> >>> Can somebody explain me a difference between DFLTPHYS and MAXPHYS >>> constants? As I understand, the last one is a maximal amount of memory, >>> that can be mapped to the kernel, or passed to the hardware drivers. But >>> why then DFLTPHYS is used in so many places and what does it mean? >> >> There's a pretty good comment on these in /sys/conf/NOTES. > > But it does not explains why. DFLTPHYS is the default -- the size to be used when the correct size is not known. However, this is mostly broken: - the correct size should always be known at a low level. You have to know the maximum size for a device to know that this size is larger than the default, else using the default size won't work. Also, you have to know that the default size is a multiple of the minimum size. Both of these are usually true accidentally, so things sort of work. - the default size is defaulted inconsistently. Geom hides the device maximum i/o size (d_maxsize, which is normally either 64K or DFLTPHYS which happen to be the same) from the top level of devices (it reblocks if necessary so that sizes up to (s_iosize_max, which is always MAXPHYS) work, so it is difficult to see the the low-level size or to use an i/o size that is a multiple of the device maximum i/o size if the latter is not a divisor or MAXPHYS. This means that hard-coding MAXPHYS would work best in most places above the driver level, but most places have a mess of buggy layering (mnt_iosize_max is supposed to default to DFLTPHYS and then be changed to si_iosize_max when the latter is known, but some file systems forget to do this). >>> Isn't it a time to review their values for increasing? 64KB looks funny, >>> comparing to modern memory sizes and data rates. It just increases >>> interrupt rates, but I don't think it really need to be so small to >>> improve interactivity now. 64K is large enough to bust modern L1 caches and old L2 caches. Make the size bigger to bust modern L2 caches too. Interrupt rates don't matter when you are transfering 64K items per interrupt. >> I wonder whether all drivers can correctly handle larger values for >> DFLTPHYS. Most can't, since their hardware can't. They can fake it (ata used to) but there is negative point in this for most drivers, since geom already reblocks for disk devices and reblocking would be wrong for devices like tapes. > There are always will be drivers/devices with limitations. They should just > be able to report that limitations to system. This is possible with GEOM, but > it doesn't looks tuned well for all providers. There are many places, when > DFLTPHYS used just with hope that it will work. IMHO if driver unable to > adapt to any defined DFLTPHYS value, it should not use it, but instead should > announce some specific value that it really supports. cam scsi devices seem to be the only important ones that still hard-code d_maxsize to DFLTPHYS. Strangely, pre-cam scsi had the beginnings (or remnants) of more sophisticated i/o size limiting. In FreeBSD-1, it has an xxminphys() function for every scsi device. I think it was supposed to be possible to ask any device for any i/o size, and minphys was used for reblocking at a low level. minphys was only implemented for scsi drivers and wasn't part of the physio() as in Net/2 (?). For the aha1542 driver, minphys was: % void % ahaminphys(bp) % struct buf *bp; % { % /* aha seems to explode with 17 segs (64k may require 17 segs) */ % /* on old boards so use a max of 16 segs if you have problems here */ % if (bp->b_bcount > ((AHA_NSEG - 1) * PAGESIZ)) { % bp->b_bcount = ((AHA_NSEG - 1) * PAGESIZ); % } % } FreeBSD-1 doesn't have DFLTPHYS, and barely uses MAXPHYS. MAXPHYS was 64K. I think MAXBSIZE = 64K limited most transfers. However, physio() uses a buffer of size 256K, larger than it does today!, so apparently, device drivers were responsible for lots of reblocking. In the wd driver, the reblocking consisted of doing 1 512-block at a time (I think it didn't even do multiple sectors per interrupt then). Bruce From gary.jennejohn at freenet.de Sun Jul 5 14:16:13 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Jul 5 14:16:20 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A50667F.7080608@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> Message-ID: <20090705161610.52e01954@ernst.jennejohn.org> On Sun, 05 Jul 2009 11:38:23 +0300 Alexander Motin wrote: > Gary Jennejohn wrote: > > I wonder whether all drivers can correctly handle larger values for > > DFLTPHYS. > > There are always will be drivers/devices with limitations. They should > just be able to report that limitations to system. This is possible with > GEOM, but it doesn't looks tuned well for all providers. There are many > places, when DFLTPHYS used just with hope that it will work. IMHO if > driver unable to adapt to any defined DFLTPHYS value, it should not use > it, but instead should announce some specific value that it really supports. > This would be the correct way to do things. I remember back in the good-old-days, circa 1985, disk drivers _always_ did their own PHYS handling so that utilities could pass in whatever value they wanted to use for the size. Of course, that meant that each driver reinvented the wheel. --- Gary Jennejohn From mav at FreeBSD.org Sun Jul 5 14:37:21 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 14:37:28 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <20090705223126.I42918@delplex.bde.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> Message-ID: <4A50BA9A.9080005@FreeBSD.org> Bruce Evans wrote: > On Sun, 5 Jul 2009, Alexander Motin wrote: >>>> Isn't it a time to review their values for increasing? 64KB looks >>>> funny, comparing to modern memory sizes and data rates. It just >>>> increases interrupt rates, but I don't think it really need to be so >>>> small to improve interactivity now. > > 64K is large enough to bust modern L1 caches and old L2 caches. Make the > size bigger to bust modern L2 caches too. Interrupt rates don't matter > when you are transfering 64K items per interrupt. How cache size related to it, if DMA transfers data directly to RAM? Sure, CPU will invalidate related cache lines, but why it should invalidate everything? Small transfers give more work to all levels from GEOM down to CAM/ATA, controllers and drives. It is not just a context switching. >>> I wonder whether all drivers can correctly handle larger values for >>> DFLTPHYS. > > Most can't, since their hardware can't. They can fake it (ata used to) > but there is negative point in this for most drivers, since geom already > reblocks for disk devices and reblocking would be wrong for devices like > tapes. I am not speaking about reblocking. I am speaking about best possible hardware usage. I can't say about the most, but at least AHCI and modern SiI SATA chips, I have worked closely, practically have no limits for transaction size, except the amount of memory their drivers allocate for S/G table. My new drivers are able to self-tune for any MAXPHYS value. -- Alexander Motin From brde at optusnet.com.au Sun Jul 5 16:46:41 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sun Jul 5 16:46:47 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A50BA9A.9080005@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> Message-ID: <20090706005851.L1439@besplex.bde.org> On Sun, 5 Jul 2009, Alexander Motin wrote: > Bruce Evans wrote: >> On Sun, 5 Jul 2009, Alexander Motin wrote: >>>>> Isn't it a time to review their values for increasing? 64KB looks funny, >>>>> comparing to modern memory sizes and data rates. It just increases >>>>> interrupt rates, but I don't think it really need to be so small to >>>>> improve interactivity now. >> >> 64K is large enough to bust modern L1 caches and old L2 caches. Make the >> size bigger to bust modern L2 caches too. Interrupt rates don't matter >> when you are transfering 64K items per interrupt. > > How cache size related to it, if DMA transfers data directly to RAM? Sure, > CPU will invalidate related cache lines, but why it should invalidate > everything? I was thinking more of transfers to userland. Increasing user buffer sizes above about half the L2 cache size guarantees busting the L2 cache, if the application actually looks at all of its data. If the data is read using read(), then the L2 cache will be busted twice (or a bit less with nontemporal copying), first by copying out the data and then by looking at it. If the data is read using mmap(), then the L2 cache will only be busted once. This effect has always been very noticeable using dd. Larger buffer sizes are also bad for latency. > Small transfers give more work to all levels from GEOM down to CAM/ATA, > controllers and drives. It is not just a context switching. Yes, I can't see any cache busting below the level of copyout(). Also, after you convert all applications to use mmap() instead of read(), the cache busting should become per-CPU. >>>> I wonder whether all drivers can correctly handle larger values for >>>> DFLTPHYS. >> >> Most can't, since their hardware can't. They can fake it (ata used to) >> but there is negative point in this for most drivers, since geom already >> reblocks for disk devices and reblocking would be wrong for devices like >> tapes. > > I am not speaking about reblocking. I am speaking about best possible > hardware usage. I can't say about the most, but at least AHCI and modern SiI > SATA chips, I have worked closely, practically have no limits for transaction > size, except the amount of memory their drivers allocate for S/G table. My > new drivers are able to self-tune for any MAXPHYS value. The main limit above ata seems to be only MAXPHYS and its use in pbufs. DFLTPHYS seems to only be used in buggy unimportant cases. Bruce From mav at FreeBSD.org Sun Jul 5 17:12:16 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 17:12:22 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <20090706005851.L1439@besplex.bde.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> Message-ID: <4A50DEE8.6080406@FreeBSD.org> Bruce Evans wrote: > On Sun, 5 Jul 2009, Alexander Motin wrote: >> Bruce Evans wrote: >>> On Sun, 5 Jul 2009, Alexander Motin wrote: >>> 64K is large enough to bust modern L1 caches and old L2 caches. Make >>> the >>> size bigger to bust modern L2 caches too. Interrupt rates don't matter >>> when you are transfering 64K items per interrupt. >> >> How cache size related to it, if DMA transfers data directly to RAM? >> Sure, CPU will invalidate related cache lines, but why it should >> invalidate everything? > > I was thinking more of transfers to userland. Increasing user buffer > sizes above about half the L2 cache size guarantees busting the L2 > cache, if the application actually looks at all of its data. If the > data is read using read(), then the L2 cache will be busted twice (or > a bit less with nontemporal copying), first by copying out the data > and then by looking at it. If the data is read using mmap(), then the > L2 cache will only be busted once. This effect has always been very > noticeable using dd. Larger buffer sizes are also bad for latency. > >> Small transfers give more work to all levels from GEOM down to >> CAM/ATA, controllers and drives. It is not just a context switching. > > Yes, I can't see any cache busting below the level of copyout(). Also, > after you convert all applications to use mmap() instead of read(), > the cache busting should become per-CPU. As soon as file data usually passing via buffer cache, they will anyway be read to the different memory areas and copied-out from them. So I don't see much difference there between doing single big and several small transactions. Cache trashing by user-level also will depends only on user-level application buffer size, but not on kernel. How to reproduce that dd experiment? I have my system running with MAXPHYS of 512K and here is what I have: # dd if=/dev/ada0 of=/dev/null bs=512k count=1000 1000+0 records in 1000+0 records out 524288000 bytes transferred in 2.471564 secs (212128024 bytes/sec) # dd if=/dev/ada0 of=/dev/null bs=256k count=2000 2000+0 records in 2000+0 records out 524288000 bytes transferred in 2.666643 secs (196609752 bytes/sec) # dd if=/dev/ada0 of=/dev/null bs=128k count=4000 4000+0 records in 4000+0 records out 524288000 bytes transferred in 2.759498 secs (189993969 bytes/sec) # dd if=/dev/ada0 of=/dev/null bs=64k count=8000 8000+0 records in 8000+0 records out 524288000 bytes transferred in 2.718900 secs (192830927 bytes/sec) CPU load instead grows from 10% at 512K to 15% at 64K. May be trashing effect will only be noticeable at block comparable to cache size, but modern CPUs have megabytes of cache. -- Alexander Motin From brde at optusnet.com.au Sun Jul 5 18:32:15 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sun Jul 5 18:32:22 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A50DEE8.6080406@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> Message-ID: <20090706034250.C2240@besplex.bde.org> On Sun, 5 Jul 2009, Alexander Motin wrote: > Bruce Evans wrote: >> I was thinking more of transfers to userland. Increasing user buffer >> sizes above about half the L2 cache size guarantees busting the L2 >> cache, if the application actually looks at all of its data. If the >> data is read using read(), then the L2 cache will be busted twice (or >> a bit less with nontemporal copying), first by copying out the data >> and then by looking at it. If the data is read using mmap(), then the >> L2 cache will only be busted once. This effect has always been very >> noticeable using dd. Larger buffer sizes are also bad for latency. > ... > How to reproduce that dd experiment? I have my system running with MAXPHYS of > 512K and here is what I have: I used a regular file with the same size as main memory (1G), and for today's test, not quite dd, but a program that throws away the data (so as to avoid overcall for write syscalls) and prints status info in a more suitable form than even dd's ^T. Your results show that physio() behaves quite differently than copying reading a regular file. I see similar behaviour input from a disk file. > # dd if=/dev/ada0 of=/dev/null bs=512k count=1000 > 1000+0 records in > 1000+0 records out > 524288000 bytes transferred in 2.471564 secs (212128024 bytes/sec) 512MB would be too small with buffering for a regular file, but should be OK with a disk file. > # dd if=/dev/ada0 of=/dev/null bs=256k count=2000 > 2000+0 records in > 2000+0 records out > 524288000 bytes transferred in 2.666643 secs (196609752 bytes/sec) > # dd if=/dev/ada0 of=/dev/null bs=128k count=4000 > 4000+0 records in > 4000+0 records out > 524288000 bytes transferred in 2.759498 secs (189993969 bytes/sec) > # dd if=/dev/ada0 of=/dev/null bs=64k count=8000 > 8000+0 records in > 8000+0 records out > 524288000 bytes transferred in 2.718900 secs (192830927 bytes/sec) > > CPU load instead grows from 10% at 512K to 15% at 64K. May be trashing effect > will only be noticeable at block comparable to cache size, but modern CPUs > have megabytes of cache. I used systat -v to estimate the load. Its average jumps around more than I like, but I don't have anything better. Sys time from dd and others is even more useless than it used to be since lots of the i/o runs in threads and the system doesn't know how to charge the application for thread time. My results (MAXPHYS is 64K, transfer rate 50MB/S, under FreeBSD-~5.2 de-geomed): regular file: block size %idle ---------- ----- 1M 87 16K 91 4K 88 (?) 512 72 (?) disk file: block size %idle ---------- ----- 1M 96 64K 96 32K 93 16K 87 8K 82 (firmware can't keep up and rate drops to 37MB/S) In the case of the regular file, almost all i/o is clustered so the driver sees mainly the cluster size (driver max size of 64K before geom). Upper layers then do a good job of only adding a few percent CPU when declustering to 16K fs-blocks. In the case of the disk file, I can't explain why the overhead is so low (~0.5% intr 3.5% sys) for large block sizes. Uncached copies on the test machine go at 850MB/S so 50MB/S should take 1/19 of the CPU or 5.3%. Another difference with the disk file test is that physio() uses a single pbuf so the test doesn't thrash the buffer cache's memory. dd of a large regular file will thrash the L2 cache even if the user buffer size is small, but still goes faster with a smaller user buffer since the user buffer stays cached. Faster disks will of course want larger block sizes. I'm still suprised that this makes more difference to CPU than throughput. Maybe it doesn't really, but the measurement becomes differently accurate when the CPU becomes more loaded. At 100% load there would be nowhere to hide things like speculative cache fetches. Bruce From mav at FreeBSD.org Sun Jul 5 18:51:13 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 18:51:20 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <20090706034250.C2240@besplex.bde.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> Message-ID: <4A50F619.4020101@FreeBSD.org> Bruce Evans wrote: > On Sun, 5 Jul 2009, Alexander Motin wrote: > >> Bruce Evans wrote: >>> I was thinking more of transfers to userland. Increasing user buffer >>> sizes above about half the L2 cache size guarantees busting the L2 >>> cache, if the application actually looks at all of its data. If the >>> data is read using read(), then the L2 cache will be busted twice (or >>> a bit less with nontemporal copying), first by copying out the data >>> and then by looking at it. If the data is read using mmap(), then the >>> L2 cache will only be busted once. This effect has always been very >>> noticeable using dd. Larger buffer sizes are also bad for latency. >> ... >> How to reproduce that dd experiment? I have my system running with >> MAXPHYS of 512K and here is what I have: > > I used a regular file with the same size as main memory (1G), and for > today's test, not quite dd, but a program that throws away the data > (so as to avoid overcall for write syscalls) and prints status info > in a more suitable form than even dd's ^T. > > Your results show that physio() behaves quite differently than copying > reading a regular file. I see similar behaviour input from a disk file. > >> # dd if=/dev/ada0 of=/dev/null bs=512k count=1000 >> 1000+0 records in >> 1000+0 records out >> 524288000 bytes transferred in 2.471564 secs (212128024 bytes/sec) > > 512MB would be too small with buffering for a regular file, but should > be OK with a disk file. > >> # dd if=/dev/ada0 of=/dev/null bs=256k count=2000 >> 2000+0 records in >> 2000+0 records out >> 524288000 bytes transferred in 2.666643 secs (196609752 bytes/sec) >> # dd if=/dev/ada0 of=/dev/null bs=128k count=4000 >> 4000+0 records in >> 4000+0 records out >> 524288000 bytes transferred in 2.759498 secs (189993969 bytes/sec) >> # dd if=/dev/ada0 of=/dev/null bs=64k count=8000 >> 8000+0 records in >> 8000+0 records out >> 524288000 bytes transferred in 2.718900 secs (192830927 bytes/sec) >> >> CPU load instead grows from 10% at 512K to 15% at 64K. May be trashing >> effect will only be noticeable at block comparable to cache size, but >> modern CPUs have megabytes of cache. > > I used systat -v to estimate the load. Its average jumps around more > than I > like, but I don't have anything better. Sys time from dd and others is > even > more useless than it used to be since lots of the i/o runs in threads and > the system doesn't know how to charge the application for thread time. > > My results (MAXPHYS is 64K, transfer rate 50MB/S, under FreeBSD-~5.2 > de-geomed): > > regular file: > > block size %idle > ---------- ----- > 1M 87 > 16K 91 > 4K 88 (?) > 512 72 (?) > > disk file: > > block size %idle > ---------- ----- > 1M 96 > 64K 96 > 32K 93 > 16K 87 > 8K 82 (firmware can't keep up and rate drops to 37MB/S) > > In the case of the regular file, almost all i/o is clustered so the driver > sees mainly the cluster size (driver max size of 64K before geom). Upper > layers then do a good job of only adding a few percent CPU when > declustering > to 16K fs-blocks. In this tests you've got almost only negative side of effect, as you have said, due to cache misses. Do you really have CPU with so small L2 cache? Some kind of P3 or old Celeron? But with 64K MAXPHYS you just didn't get any benefit from using bigger block size. -- Alexander Motin From mav at FreeBSD.org Sun Jul 5 19:16:35 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Jul 5 19:16:42 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> Message-ID: <4A50FC0B.9090601@FreeBSD.org> Adrian Chadd wrote: > 2009/7/6 Alexander Motin : > >> In this tests you've got almost only negative side of effect, as you have >> said, due to cache misses. Do you really have CPU with so small L2 cache? >> Some kind of P3 or old Celeron? But with 64K MAXPHYS you just didn't get any >> benefit from using bigger block size. > > All the world isn't your current desktop box with only SATA devices :) This is laptop and what do you mean by "only SATA"? You know any storage which performance degrade from big transactions? > There have been and will be plenty of little embedded CPUs with tiny > amounts of cache for quite some time to come. Fine, lets set it to 8K on ARM. What do want to say by that? > You're also doing simple stream IO tests. Please re-think the thought > experiment with a whole lot of parallel IO going on rather than just > straight single stream IO. Please don't. Parallel access with big blocks becomes just more linear with growing block length. For modern drives with >100MB/s speeds and 10ms access time it is just a madness to transfer less then 1MB in one transaction with random access. > Also, please realise that part of having your cache thrashed is what > it does to the performance of -other- code. dd may be fast, but if > you're constantly purging your caches by copying around all of that > data, subsequent code has to go and freshen the cache again. On older > and anaemic embedded/low power boxes the cost of a cache miss vs cache > hit can still be quite expensive. I think that anaemic embedded/low power boxes will prefer to handle operation by chipset hardware as much as possible without interrupting CPU. Also please read one of my previous posts. I don't see why, with, for example, 1M user-level buffer, buffer-cache backed access spited into many small disk transactions could less trash CPU cache. It just transmit same amount of data into the same buffer cachememory addresses. It is not a disk transaction DMA size trashes the cache. If you want to fight it - OK, but not there. -- Alexander Motin From adrian at freebsd.org Sun Jul 5 19:25:39 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Sun Jul 5 19:25:46 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A50F619.4020101@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> Message-ID: 2009/7/6 Alexander Motin : > In this tests you've got almost only negative side of effect, as you have > said, due to cache misses. Do you really have CPU with so small L2 cache? > Some kind of P3 or old Celeron? But with 64K MAXPHYS you just didn't get any > benefit from using bigger block size. All the world isn't your current desktop box with only SATA devices :) There have been and will be plenty of little embedded CPUs with tiny amounts of cache for quite some time to come. You're also doing simple stream IO tests. Please re-think the thought experiment with a whole lot of parallel IO going on rather than just straight single stream IO. Also, please realise that part of having your cache thrashed is what it does to the performance of -other- code. dd may be fast, but if you're constantly purging your caches by copying around all of that data, subsequent code has to go and freshen the cache again. On older and anaemic embedded/low power boxes the cost of a cache miss vs cache hit can still be quite expensive. 2c, Adrian From dillon at apollo.backplane.com Mon Jul 6 01:14:21 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Mon Jul 6 01:14:27 2009 Subject: DFLTPHYS vs MAXPHYS References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> Message-ID: <200907060114.n661EK68065706@apollo.backplane.com> I think MAXPHYS, or the equivalent, is still used somewhat in the clustering code. The number of buffers the clustering code decides to chain together dictates the impact on the actual device. The relevancy here has very little to do with cache smashing and more to do with optimizing disk seeks (or network latency). There is no best value for this. It is only marginally more interesting for a network interface due to the fact that most links still run with absurdly small MTUs (even 9000+ is absurdly small). It is entirely uninteresting for a SATA or other modern disk link. For linear transfers you only need a value sufficiently large to reduce the impact of command overhead on the cpu and achieve the device's maximum linear transfer rate For example, doing a dd with bs=512 verses bs=32k. It runs on a curve and there will generally be very little additional bang for the buck beyond 64K for a linear transfer (assuming read ahead and NCQ to reduce inter-command latency). For random and semi-random transfers a larger buffer sizes have two impacts. First is a negative impact on seek times. A random seek-read of 16K is faster then a random seek-read of 64K is faster then a random seek-read of 512K. I did a ton of testing with HAMMER and it just didn't make much sense to go beyond 128K, frankly, but neither does it make sense to use something really tiny like 8K. 32K-128K seems to be the sweet spot. The second is a positive impact on reducing the total number of seeks *IF* you have reasonable cache locality of reference. There is no correct value, it depends heavily on the access pattern. A random access pattern with very little locality of reference will benefit from a smaller block size while a random access pattern with high locality of reference will benefit from a larger block size. That's all there is to it. I have a fairly negative opinion of trying to tune block size to cpu caches. I don't think it matters nearly as much as tuning it to the seek/locality-of-reference performace curve, and I don't feel that contrived linear tests are all that interesting since they don't really reflect real-life work-loads. on-drive caching has an impact too, but that's another conversation. Vendors have been known to intentionally degrade drive cache performance on consumer drives verses commercial drives. I've often hit limitations in testing HAMMER which seem to be contrived by vendors that would have allowed me to use a smaller block size and still get the locality of reference, but I wind up having to use a larger one because the drive cache doesn't behave sanely. -- The DMA ability of modern devices and device drivers is pretty much moot as no self respecting disk controller chipset will be limited to a measily 64K max transfer any more. AHCI certainly has no issue doing in excess of a megabyte. The limit is something like 65535 chained entries for AHCI. I forget what the spec says exactly but it's basically more then we'd ever really need. Nobody should really care about the performance of a chipset that is limited to a 64K max transfer. As long as the cluster code knows what the device can do and the filesystem doesn't try to use a larger block size the device is capable of in a single BIO, the cluster code will make up the difference for any device-based limitations. -Matt From bugmaster at FreeBSD.org Mon Jul 6 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 6 11:07:31 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200907061106.n66B6rFs010680@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From brde at optusnet.com.au Mon Jul 6 15:54:18 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Mon Jul 6 15:54:25 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <4A50F619.4020101@FreeBSD.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> Message-ID: <20090707011217.O43961@delplex.bde.org> On Sun, 5 Jul 2009, Alexander Motin wrote: > Bruce Evans wrote: >> My results (MAXPHYS is 64K, transfer rate 50MB/S, under FreeBSD-~5.2 >> de-geomed): >> >> regular file: >> >> block size %idle >> ---------- ----- >> 1M 87 >> 16K 91 >> 4K 88 (?) >> 512 72 (?) >> >> disk file: >> >> block size %idle >> ---------- ----- >> 1M 96 >> 64K 96 >> 32K 93 >> 16K 87 >> 8K 82 (firmware can't keep up and rate drops to 37MB/S) >> >> In the case of the regular file, almost all i/o is clustered so the driver >> sees mainly the cluster size (driver max size of 64K before geom). Upper >> layers then do a good job of only adding a few percent CPU when >> declustering >> to 16K fs-blocks. > > In this tests you've got almost only negative side of effect, as you have > said, due to cache misses. No, I got negative and positive for the regular file (due to cache misses for large block sizes and too many transactions for very small block sizes (< 16K), and only positive for the disk file (due to cache misses not being tested). > Do you really have CPU with so small L2 cache? > Some kind of P3 or old Celeron? It is 1M as stated on an A64 (not stated). Since the disk file case ses a pbuf, it only thrashes about half as much cache as the regular file, provided the used part of the pbuf data is small compared with the cache size. I forgot to test with a user buffer size of 2M. > But with 64K MAXPHYS you just didn't get any > benefit from using bigger block size. MAXPHYS is 128K. The ata driver has a limit of 64K so anything larger than 64K wouldn't do much except increase cache misses. In physio(), it would just causes physio() to ask the driver to read 64K at a time. My claim is partly that 64K such a large size that the extra CPU caused by splitting up into 64K-blocks is insignificant. Here are better results for the disk file test, with cache accesses and misses counted by perfmon: % dd if=/dev/ad2 of=/dev/null bs=16384 count=16384 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.857302 secs (55264313 bytes/sec) % 146378905 % # s/kx-dc-misses % 268435456 bytes transferred in 4.782373 secs (56130180 bytes/sec) % 946562 % dd if=/dev/ad2 of=/dev/null bs=32768 count=8192 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.715802 secs (56922546 bytes/sec) % 79404995 % # s/kx-dc-misses % 268435456 bytes transferred in 4.749098 secs (56523463 bytes/sec) % 640427 % dd if=/dev/ad2 of=/dev/null bs=65536 count=4096 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.740766 secs (56622802 bytes/sec) % 45633277 % # s/kx-dc-misses % 268435456 bytes transferred in 4.882316 secs (54981173 bytes/sec) % 424469 Cache misses are minimized here using a user buffer size of 64K. % dd if=/dev/ad2 of=/dev/null bs=131072 count=2048 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.873972 secs (55075298 bytes/sec) % 42296347 % # s/kx-dc-misses % 268435456 bytes transferred in 4.940565 secs (54332946 bytes/sec) % 497104 % dd if=/dev/ad2 of=/dev/null bs=262144 count=1024 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.982193 secs (53878976 bytes/sec) % 38617107 % # s/kx-dc-misses % 268435456 bytes transferred in 4.715697 secs (56923816 bytes/sec) % 522888 % dd if=/dev/ad2 of=/dev/null bs=524288 count=512 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.957179 secs (54150849 bytes/sec) % 37115853 % # s/kx-dc-misses % 268435456 bytes transferred in 4.923855 secs (54517338 bytes/sec) % 521308 % dd if=/dev/ad2 of=/dev/null bs=1048576 count=256 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.707334 secs (57024946 bytes/sec) % 36526303 Cache accesses are minimized here using a user buffer size of 1M. % # s/kx-dc-misses % 268435456 bytes transferred in 4.715655 secs (56924319 bytes/sec) % 541909 % dd if=/dev/ad2 of=/dev/null bs=2097152 count=128 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.715631 secs (56924610 bytes/sec) % 36628946 % # s/kx-dc-misses % 268435456 bytes transferred in 4.707306 secs (57025284 bytes/sec) % 534541 Cache misses are only increased a little here with a user buffer size of 2M. I can't explain this. Maybe I misremember my CPU's cache size. % dd if=/dev/ad2 of=/dev/null bs=4194304 count=64 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.965433 secs (54060837 bytes/sec) % 37688487 % # s/kx-dc-misses % 268435456 bytes transferred in 4.740570 secs (56625145 bytes/sec) % 2443717 Cache misses increased by a factor of 5 going from user buffer size 2M to 4M. % dd if=/dev/ad2 of=/dev/null bs=8388608 count=32 % # s/kx-dc-accesses % 268435456 bytes transferred in 5.056997 secs (53081988 bytes/sec) % 39425354 % # s/kx-dc-misses % 268435456 bytes transferred in 4.907099 secs (54703493 bytes/sec) % 589090 % dd if=/dev/ad2 of=/dev/null bs=16777216 count=16 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.998672 secs (53701354 bytes/sec) % 49361807 % # s/kx-dc-misses % 268435456 bytes transferred in 4.732208 secs (56725202 bytes/sec) % 603496 % dd if=/dev/ad2 of=/dev/null bs=33554432 count=8 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.965315 secs (54062119 bytes/sec) % 61536416 % # s/kx-dc-misses % 268435456 bytes transferred in 4.882041 secs (54984269 bytes/sec) % 3947985 % dd if=/dev/ad2 of=/dev/null bs=67108864 count=4 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.857003 secs (55267715 bytes/sec) % 78234741 % # s/kx-dc-misses % 268435456 bytes transferred in 4.931896 secs (54428448 bytes/sec) % 8580752 % dd if=/dev/ad2 of=/dev/null bs=134217728 count=2 % # s/kx-dc-accesses % 268435456 bytes transferred in 4.815146 secs (55748145 bytes/sec) % 124758517 % # s/kx-dc-misses % 268435456 bytes transferred in 4.865137 secs (55175312 bytes/sec) % 13808781 Cache misses increased by a another factor of 5 going from user buffer size 4M to 128M. I can't explain why there are as many as 13.8 million -- I would have expected 2*256M/64 = 8M only, but in more cases. 8 million cache misses in only 4.8 seconds is a lot, and you would get that many in only 1.3 seconds at 200MB/S. Of course, 128M is a silly buffer size, but I would expect the cache effects to show up at about half the L2 size under more realistic loads. Cache accesses varied significantly, between 146 million (block size 16384), 37 million (block size 1M) and 138 million (block size 128M). I can only partly explain this. I think the minimum number is 2*256M/16 = 32M (for fetching from L2 to L1 16 bytes at a time). 128M might result from fetching 4 bytes at a time or thrashing causing the equivalent. Bruce From mav at FreeBSD.org Mon Jul 6 17:00:58 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Jul 6 17:01:04 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <20090707011217.O43961@delplex.bde.org> References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> <20090707011217.O43961@delplex.bde.org> Message-ID: <4A522DC1.2080908@FreeBSD.org> Bruce Evans wrote: > On Sun, 5 Jul 2009, Alexander Motin wrote: >> In this tests you've got almost only negative side of effect, as you >> have said, due to cache misses. > > No, I got negative and positive for the regular file (due to cache misses > for large block sizes and too many transactions for very small block sizes > (< 16K), and only positive for the disk file (due to cache misses not > being tested). No, I mean that you didn't get any benefit from increasing from disk I/O transaction sizes. You still were limited by 64K. >> But with 64K MAXPHYS you just didn't get any benefit from using bigger >> block size. > > MAXPHYS is 128K. The ata driver has a limit of 64K so anything larger > than 64K wouldn't do much except increase cache misses. In physio(), > it would just causes physio() to ask the driver to read 64K at a time. > My claim is partly that 64K such a large size that the extra CPU caused > by splitting up into 64K-blocks is insignificant. ATA subsystem allows drivers to have different transaction sizes. At least AHCI driver can do more. What is about insignificant - I have shown example, when it is not completely so. > Here are better results for the disk file test, with cache accesses and > misses counted by perfmon: > > Cache misses are minimized here using a user buffer size of 64K. > > Cache accesses are minimized here using a user buffer size of 1M. > > Cache misses increased by a factor of 5 going from user buffer size > 2M to 4M. > > Cache misses increased by a another factor of 5 going from user buffer > size 4M to 128M. I can't explain why there are as many as 13.8 million > -- I would have expected 2*256M/64 = 8M only, but in more cases. 8 > million cache misses in only 4.8 seconds is a lot, and you would get > that many in only 1.3 seconds at 200MB/S. Of course, 128M is a silly > buffer size, but I would expect the cache effects to show up at about > half the L2 size under more realistic loads. > > Cache accesses varied significantly, between 146 million (block size > 16384), 37 million (block size 1M) and 138 million (block size 128M). > I can only partly explain this. I think the minimum number is > 2*256M/16 = 32M (for fetching from L2 to L1 16 bytes at a time). > 128M might result from fetching 4 bytes at a time or thrashing causing > the equivalent. I think on small transaction size cache misses could be caused not by transfered data itself, but by different variables addressed by code. Growing number of misses on bigger blocks is also predictable. Working with regular file could giva a different results, as soon as data will not be read into the same memory, but over the all buffer cache. And once more I want to say that you are testing not the same I was speaking about. I agree that enormous block size in user-level will affect cache efficiency negatively, just because of large am mounts of data moved by CPU. What I wanted to say is that IMHO allowing device to transfer data with bigger blocks, when needed, will give positive effect for both I/O hardware and CPU usage effectiveness, without significant affect for caching, as caches are mostly trashed not there, but in completely different places. -- Alexander Motin From dillon at apollo.backplane.com Mon Jul 6 18:12:48 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Mon Jul 6 18:12:57 2009 Subject: DFLTPHYS vs MAXPHYS References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> <20090707011217.O43961@delplex.bde.org> <4A522DC1.2080908@FreeBSD.org> Message-ID: <200907061812.n66ICkTc075260@apollo.backplane.com> Linear dd tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 11 0.50 17511 8.55 0 0 15 0 85 bs=512 0 11 1.00 16108 15.73 0 0 12 0 87 bs=1024 0 11 2.00 14758 28.82 0 0 11 0 89 bs=2048 0 11 4.00 12195 47.64 0 0 7 0 93 bs=4096 0 11 8.00 8026 62.70 0 0 5 0 95 bs=8192 << MB/s breakpt 0 11 16.00 4018 62.78 0 0 4 0 96 bs=16384 0 11 32.00 2025 63.28 0 0 2 0 98 bs=32768 << id breakpt 0 11 64.00 1004 62.75 0 0 1 0 99 bs=65536 0 11 128.00 506 63.25 0 0 1 0 99 bs=131072 Random seek/read tty da0 cpu tin tout KB/t tps MB/s us ni sy in id 0 11 0.50 189 0.09 0 0 0 0 100 bs=512 0 11 1.00 184 0.18 0 0 0 0 100 bs=1024 0 11 2.00 177 0.35 0 0 0 0 100 bs=2048 0 11 4.00 175 0.68 0 0 0 0 100 bs=4096 0 11 8.00 172 1.34 0 0 0 0 100 bs=8192 0 11 16.00 166 2.59 0 0 0 0 100 bs=16384 0 11 32.00 159 4.97 0 0 1 0 99 bs=32768 0 11 64.00 142 8.87 0 0 0 0 100 bs=65536 0 11 128.00 117 14.62 0 0 0 0 100 bs=131072 ^^^ ^^^ note TPS rate and MB/s Which is the more important tuning variable? Efficiency of linear reads or saving re-seeks by buffering more data? If you didn't choose saving re-seeks you lose. To go from 16K to 32K requires saving 5% of future re-seeks to break-even. To go from 32K to 64K requires saving 11% of future re-seeks. To go from 64K to 128K requires saving 18% of future re-seeks. (at least with this particular disk) At the point where the block size exceeds 32768 if you aren't saving re-seeks with locality of reference from the additional cached data, you lose. If you are saving reseeks you win. cpu caches do not enter into the equation at all. For most filesystems the re-seeks being saved depend on the access pattern. For example, if you are doing a ls -lR or a find the re-seek pattern will be related to inode and directory lookups. The number of inodes which fit in a cluster_read(), assuming reasonable locality of reference, will wind up determining the performance. However, as the buffer size grows the total number of bytes you are able to cache becomes the dominant factor in calculating the re-seek efficiency. I don't have a graph for that but, ultimately, it means that reading very large blocks (i.e. 1MB) with a non-linear access pattern is bad because most of the additional data cached will never be used before the memory winds up being re-used to cache some other cluster. Another thing to note here is that command transfer overhead also becomes mostly irrelevant once you hit 32K, even if you have a lot of discrete disks. I/O's of less then 8KB are clearly wasteful of resources (in my test even a linear transfer couldn't achieve the bandwidth ceiling of the device). I/O's greater then 32K are clearly dependant on saving re-seeks. Note in particular that the data transfer rate for random I/O doubles as the buffer size doubles when you have a random access pattern (because seek times are so long). In otherwords, it's a huge win if you are actually able to save future re-seeks by caching the additional data. What this all means is that cpu caches are basically irrelevant when it comes to hard drive I/O. You are either saving enough re-seeks to make up for the greater seek latency or you aren't. One re-seek is something like 7ms. 7ms is a LONG time, which is why the cpu caches are irrelevant for choosing the block size. One can bean-count cache misses all day long but it won't make the machine perform any better in this case. -Matt From communications_msn_cs_ptbr at Microsoft.msn.com Tue Jul 7 05:32:17 2009 From: communications_msn_cs_ptbr at Microsoft.msn.com (Equipe Windows Live) Date: Tue Jul 7 05:32:52 2009 Subject: Ultimo aviso seu email Hotmail sera excluido em ate 24 horas. Message-ID: <200907070504.n6752hR7022858@venkobrasil.com.br> Caso n?o esteja visualizando este e-mail, clique aqui Caro usu?rio, sua caixa de mensagens eletr?nicas ( e-mail ) est? em processo de exclus?o dentro de 48 horas se n?o for efetuada a revalida??o, ele ser? infelizmente deletado do Hotmail. Para sua Tranq?ilidade, voc? pode optar por validar ou cancelar. Siga as instru??es: Revalidar o correio eletr?nico: O processo para revalidar ser? efetuado ap?s a entrada em nosso link, para revalidar, clique abaixo e depois v? em abrir. Revalidar Correio eletr?nico: Ativar Conta Cancelar o correio eletr?nico: Se voc? optar por cancelar, voc? pode esperar 48 horas que ser? automaticamente deletado do sistema, ou clique abaixo e depois v? em abrir. Cancelar o Correio eletr?nico: Cancelar Conta Este e-mail ? apenas informativo, serve unicamente como notifica??o, n?o responda. Equipe Hotmail 2009 Microsoft e seus fornecedores. Todos os direitos reservados From mav at FreeBSD.org Tue Jul 7 13:26:34 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jul 7 13:26:41 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <1246915383.00136290.1246904409@10.7.7.3> References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> Message-ID: <4A534D05.1040709@FreeBSD.org> Matthew Dillon wrote: > tty da0 cpu > tin tout KB/t tps MB/s us ni sy in id > 0 11 0.50 17511 8.55 0 0 15 0 85 bs=512 > 0 11 1.00 16108 15.73 0 0 12 0 87 bs=1024 > 0 11 2.00 14758 28.82 0 0 11 0 89 bs=2048 > 0 11 4.00 12195 47.64 0 0 7 0 93 bs=4096 > 0 11 8.00 8026 62.70 0 0 5 0 95 bs=8192 << MB/s breakpt > 0 11 16.00 4018 62.78 0 0 4 0 96 bs=16384 > 0 11 32.00 2025 63.28 0 0 2 0 98 bs=32768 << id breakpt > 0 11 64.00 1004 62.75 0 0 1 0 99 bs=65536 > 0 11 128.00 506 63.25 0 0 1 0 99 bs=131072 As I have written before, my SSD continues to improve speed up to 512KB transaction size, and may be farther, I haven't tested > Random seek/read > > tty da0 cpu > tin tout KB/t tps MB/s us ni sy in id > 0 11 0.50 189 0.09 0 0 0 0 100 bs=512 > 0 11 1.00 184 0.18 0 0 0 0 100 bs=1024 > 0 11 2.00 177 0.35 0 0 0 0 100 bs=2048 > 0 11 4.00 175 0.68 0 0 0 0 100 bs=4096 > 0 11 8.00 172 1.34 0 0 0 0 100 bs=8192 > 0 11 16.00 166 2.59 0 0 0 0 100 bs=16384 > 0 11 32.00 159 4.97 0 0 1 0 99 bs=32768 > 0 11 64.00 142 8.87 0 0 0 0 100 bs=65536 > 0 11 128.00 117 14.62 0 0 0 0 100 bs=131072 > ^^^ ^^^ > note TPS rate and MB/s > > Which is the more important tuning variable? Efficiency of linear > reads or saving re-seeks by buffering more data? If you didn't choose > saving re-seeks you lose. > > To go from 16K to 32K requires saving 5% of future re-seeks to break-even. > To go from 32K to 64K requires saving 11% of future re-seeks. > To go from 64K to 128K requires saving 18% of future re-seeks. > (at least with this particular disk) > > At the point where the block size exceeds 32768 if you aren't saving > re-seeks with locality of reference from the additional cached data, > you lose. If you are saving reseeks you win. cpu caches do not enter > into the equation at all. > > For most filesystems the re-seeks being saved depend on the access > pattern. For example, if you are doing a ls -lR or a find the re-seek > pattern will be related to inode and directory lookups. The number of > inodes which fit in a cluster_read(), assuming reasonable locality of > reference, will wind up determining the performance. > > However, as the buffer size grows the total number of bytes you are > able to cache becomes the dominant factor in calculating the re-seek > efficiency. I don't have a graph for that but, ultimately, it means > that reading very large blocks (i.e. 1MB) with a non-linear access > pattern is bad because most of the additional data cached will never > be used before the memory winds up being re-used to cache some other > cluster. You are mixing completely different things. I was never talking about file system block size. I am not trying to argue that 16/32K file system block size may be quite effective in most of cases. I was speaking about maximum _disk_transaction_ size. It is not the same. When file system needs small amount of data, or there is just small file, there is definitely no need to read/write more then one small FS block. But instead, when file system prognoses effective large read-ahead or it have a lot of write-back data, there is no reason to not transfer more contiguous blocks with one big disk transaction. Splitting it will just increase command overhead at all layers and make possible drive to be interrupted between that operations to do some very long seek. -- Alexander Motin From dillon at apollo.backplane.com Tue Jul 7 16:36:43 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 7 16:36:49 2009 Subject: DFLTPHYS vs MAXPHYS References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org> Message-ID: <200907071636.n67GagxN087660@apollo.backplane.com> :You are mixing completely different things. I was never talking about :file system block size. I am not trying to argue that 16/32K file system :block size may be quite effective in most of cases. I was speaking about :maximum _disk_transaction_ size. It is not the same. : :When file system needs small amount of data, or there is just small :file, there is definitely no need to read/write more then one small FS :block. But instead, when file system prognoses effective large :read-ahead or it have a lot of write-back data, there is no reason to :not transfer more contiguous blocks with one big disk transaction. :Splitting it will just increase command overhead at all layers and make :possible drive to be interrupted between that operations to do some very :long seek. :-- :Alexander Motin That isn't correct. Locality of reference for adjacent data is very important even if the filesystem only needs a small amount of data. A good example of this would be accessing the inode area in a UFS cylinder. Issuing only a single filesystem block read in the inode area is a huge lose verses issueing a cluster read of 64K (4-8 filesystem blocks), particularly if the inode is being accessed as part of a 'find' or 'ls -lR'. I have not argued that the maximum device block size is important, I've simply argued that it is convenient. What is important, and I stressed this in my argument several times, is the total number of bytes the cluster_read() code reads when the filesystem requests a particular filesystem block. -Matt Matthew Dillon From dillon at apollo.backplane.com Tue Jul 7 17:10:29 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 7 17:10:35 2009 Subject: DFLTPHYS vs MAXPHYS References: <20090707151901.GA63927@les.ath.cx> <200907071639.n67GdBD2087690@apollo.backplane.com> Message-ID: <200907071710.n67HASb7088248@apollo.backplane.com> A more insideous problem here that I think is being missed is the fact that newer filesystems are starting to use larger filesystem block sizes. I myself hit serious issues when I tried to create a UFS filesystem with a 64K basic filesystem block size a few years ago, and I hit similar issues with HAMMER which uses 64K buffers for bulk data which I had to fix by reincorporating code into ATA that had existed originally to break-up large single-transfer requests that exceeded the chipset's DMA capability. In the case of ATA, numerous older chips can't even do 64K due to bugs in the DMA hardware. Their maximum is actually 65024 bytes. Traditionally the cluster code enforced such limits but assumed that the basic filesystem block size would be small enough not to hit the limits. It becomes a real problem when the filesystem itself wants to use a large basic block size. In that respect hardware which is limited to 64K has serious consequences which cascade through to the VFS layers. -Matt From mav at FreeBSD.org Tue Jul 7 18:25:50 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jul 7 18:25:57 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <200907071636.n67GagxN087660@apollo.backplane.com> References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org> <200907071636.n67GagxN087660@apollo.backplane.com> Message-ID: <4A53931D.6040307@FreeBSD.org> Matthew Dillon wrote: > That isn't correct. Locality of reference for adjacent data is very > important even if the filesystem only needs a small amount of data. All I wanted to say, is that it is FS privilege to decide how much data it needs. But when it really needs a lot of data, they should be better transferred with smaller number of bigger transactions, without strict MAXPHYS limitation. -- Alexander Motin From dillon at apollo.backplane.com Tue Jul 7 19:02:14 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 7 19:02:22 2009 Subject: DFLTPHYS vs MAXPHYS References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org> <200907071636.n67GagxN087660@apollo.backplane.com> <4A53931D.6040307@FreeBSD.org> Message-ID: <200907071902.n67J2Dcm090246@apollo.backplane.com> :All I wanted to say, is that it is FS privilege to decide how much data :it needs. But when it really needs a lot of data, they should be better :transferred with smaller number of bigger transactions, without strict :MAXPHYS limitation. : :-- :Alexander Motin We are in agreement. That's essentially what I mean by all my cluster_read() comments. What matters the most is how much read-ahead the cluster code does, and how well matched the read-ahead is on reducing future transactions, and not so much on anything else (such as cpu caches). The cluster heuristics are pretty good but they do break down under certain circumstances. For example, for UFS they break down when there is file data adjacency between different inodes. That is often why one sees the KB/t sizes go down (and the TPS rate go up) when tar'ing up a large number of small files. taring up /usr/src is a good example of this. KB/t can drop all the way down to 8K and performance is noticably degraded. The cluster heuristic also tends to break down on the initial read() from a newly constituted vnode, because it has no prior history to work with and so does not immediately issue a read-ahead even though the I/O may end up being linear. -- For command latency issues Julian pointed out a very interesting contrast between a HD and a (SATA) SSD. With no seek times to speak of command overhead becomes a bigger deal when trying to maximize the peformance of a SSD. I would guess that larger DMA transactions (from the point of view of the host cpu anyhow) would be more highly desired once we start hitting bandwidth ceilings of 300 MBytes/sec for SATA II and 600 MBytes/sec beyond that. If in my example the bandwidth ceiling for a HD capable of doing 60MB/s is hit at the 8K mark then presumably the block size needed to hit the bandwidth ceiling for a HD or SSD capable of 200MB/s, or 300MB/s, or higher, will also have to be larger. 16K, 32K, etc. This is fast approaching the 64K mark people are arguing about. In anycase, the main reason I posted is to try to correct people's assumptions on the importance of various parameters, particularly the irrelevancy of cpu caches in the bigger picture. -Matt Matthew Dillon From brde at optusnet.com.au Tue Jul 7 21:12:44 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Tue Jul 7 21:12:51 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: <200907071902.n67J2Dcm090246@apollo.backplane.com> References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org> <200907071636.n67GagxN087660@apollo.backplane.com> <4A53931D.6040307@FreeBSD.org> <200907071902.n67J2Dcm090246@apollo.backplane.com> Message-ID: <20090708062346.G1555@besplex.bde.org> On Tue, 7 Jul 2009, Matthew Dillon wrote: > :All I wanted to say, is that it is FS privilege to decide how much data > :it needs. But when it really needs a lot of data, they should be better > :transferred with smaller number of bigger transactions, without strict > :MAXPHYS limitation. > : > :-- > :Alexander Motin > > We are in agreement. That's essentially what I mean by all my > cluster_read() comments. I did not disagree. One of my points is that fs's are currently limited by MAXPHYS and that simply increasing MAXPHYS isn't free. > What matters the most is how much read-ahead > the cluster code does, and how well matched the read-ahead is on > reducing future transactions, and not so much on anything else (such as > cpu caches). I will disagree with most of this - the amount of read-ahead/clustering is not very important. fs's already depend on the drive doing significant buffering, so that when the fs gets things and seeks around a lot, not all the seeks are physical. Locality is much more important. - cpu caches are already of minor importance and will become more important as drives become faster. > The cluster heuristics are pretty good but they do break down under > certain circumstances. For example, for UFS they break down when there > is file data adjacency between different inodes. That is often why one > sees the KB/t sizes go down (and the TPS rate go up) when tar'ing up a > large number of small files. taring up /usr/src is a good example of > this. KB/t can drop all the way down to 8K and performance is noticably > degraded. At least for ffs in FreeBSD, this is mostly locality, not clustering. Tarring up /usr/src to test optimizations of locality is one of my favourite benchmarks. Since ffs does no inter-file or inode clustering, the average i/o size is smaller than the average file size. Since files in /usr/src are small, you are lucky if the average i/o size is 8K (the average file size is actually between 8K and and 16K). Since the ffs block size is larger than the file size, most file data fits in a single block and clustering has no effect. (But I also like to optimize and test file systems with a small block size. Clustering makes a big difference for msdosfs with a block size of 512, and in this benchmark, after my optimizations, msdosfs with a block size of 512 is slightly faster than unoptimized ffs with a block size of 16K. The smaller block size just takes more CPU. msdosfs is fundamentally faster than ffs for small files since it has better locality (no inodes, and better locality for the FAT than for indirect blocks).) > The cluster heuristic also tends to break down on the initial read() from > a newly constituted vnode, because it has no prior history to work with > and so does not immediately issue a read-ahead even though the I/O may > end up being linear. This is harmful for random file access, but for tarring up /user/src there is a good chance that file locality (in directory traversal order) combined with read-ahead in the drive will compensate for this. > For command latency issues Julian pointed out a very interesting contrast > between a HD and a (SATA) SSD. With no seek times to speak of command > overhead becomes a bigger deal when trying to maximize the peformance > of a SSD. I would guess that larger DMA transactions (from the point of > view of the host cpu anyhow) would be more highly desired once we start > hitting bandwidth ceilings of 300 MBytes/sec for SATA II and > 600 MBytes/sec beyond that. It is actually already a problem (the problem of this thread). Even at 50MB/S, I see some slowness due to command latency (I see increased CPU but that is similar to latency in the context of this thread). Alexander has 200MB/S disks so he sees larger problems. My CPU overhead (on a ~2GHz CPU) is about 50 uS/block. With 64K-blocks at 50MB/S, this gives a CPU overhead of 40 mS/S or 4%. Not significant. With 16K-blocks at 50MB/S, this gives a CPU overhead of 16%. This is becoming significant. At 200MB/S, the overhead would be 16% even for 64K-blocks. Alexander reported savings of 10-15% using 512K-blocks. This is consistent. > If in my example the bandwidth ceiling for a HD capable of doing 60MB/s > is hit at the 8K mark then presumably the block size needed to hit the > bandwidth ceiling for a HD or SSD capable of 200MB/s, or 300MB/s, or > higher, will also have to be larger. 16K, 32K, etc. This is fast > approaching the 64K mark people are arguing about. I thought we were arguing about the 512K and 1M marks :-). I haven't been worrying about command latency and didn't notice that we were discussing an SSD before. At hundreds of MB/S, or for zero-latency hardware, the command overhead becomes a limiting factor for throughput. > In anycase, the main reason I posted is to try to correct people's > assumptions on the importance of various parameters, particularly the > irrelevancy of cpu caches in the bigger picture. My examples show that the CPU cache can be relevant even with a 50MB/S disk. With faster disks it becomes even more relevant. It is hard to keep up with 200MB/S, and harder if you double the number of cache misses using large buffers. Bruce From dillon at apollo.backplane.com Tue Jul 7 22:15:37 2009 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Tue Jul 7 22:15:45 2009 Subject: DFLTPHYS vs MAXPHYS References: <1246746182.00135530.1246735202@10.7.7.3> <1246792983.00135712.1246781401@10.7.7.3> <1246796580.00135722.1246783203@10.7.7.3> <1246814582.00135806.1246803602@10.7.7.3> <1246818181.00135809.1246804804@10.7.7.3> <1246825383.00135846.1246812602@10.7.7.3> <1246825385.00135854.1246814404@10.7.7.3> <1246830930.00135868.1246819202@10.7.7.3> <1246830933.00135875.1246820402@10.7.7.3> <1246908182.00136258.1246896003@10.7.7.3> <1246911786.00136277.1246900203@10.7.7.3> <1246915383.00136290.1246904409@10.7.7.3> <4A534D05.1040709@FreeBSD.org> <200907071636.n67GagxN087660@apollo.backplane.com> <4A53931D.6040307@FreeBSD.org> <200907071902.n67J2Dcm090246@apollo.backplane.com> <20090708062346.G1555@besplex.bde.org> Message-ID: <200907072215.n67MFZeM092096@apollo.backplane.com> :I will disagree with most of this :- the amount of read-ahead/clustering is not very important. fs's already : depend on the drive doing significant buffering, so that when the fs gets : things and seeks around a lot, not all the seeks are physical. Locality : is much more important. Yes, I agree with you there to a point, but drive cache performance tails off very quickly if things are not exactly sequential in each zone being read, and it is fairly difficult to achieve exact sequentiality in the filesystem layout. Also command latency really starts to interfere if you have to go to the drive every few name lookups / stats / whatever since those operations only take a few microseconds if the data is sitting in the buffer cache, even if its just going to the HD's on-drive cache. The cluster code fixes both the command latency issue and the problem of slight non-sequentialities in the access pattern (in each zone being seek-read). Without it performance numbers will wind up being all over the board. That makes it fairly important. I got a nifty program to test that. fetch http://apollo.backplane.com/DFlyMisc/zoneread.c cc ... (^C to stop test, use iostat to see the results) ./zr /dev/da0 16 16 1024 1 ./zr /dev/da0 16 16 1024 2 ./zr /dev/da0 16 16 1024 3 ./zr /dev/da0 16 16 1024 4 If you play with it you will find that most drives can track around 16 zones and 100% sequential forward reads in each zone. Any other access pattern severely degrades performance. For example if you read the data in reverse you can kiss goodbyte to performance. If you introduce slight non-linearities in the access pattern, even though the seeks are within 16-32K of each other, performance degrades very rapidly. This is what I mean by drives not doing sane caching. It was ok with smaller drives where the non-linearities were hitting up against the need to do an actual head seek, but the drive caches in today's huge drives are just not tuned very well. UFS does have a bit of advantage here but HAMMER does a fairly good job too. The problem HAMMER has is with its initial layout due to B-Tree node splits (which messes up linearity in the B-Tree). Once the reblocker cleans up the B-Tree performance is recovered. The B-Tree is the biggest problem, but I can't fix the initial layout without making incompatible media changes so I'm holding off on doing it for now. -Matt From mailing at gaturkey.com Thu Jul 9 16:36:49 2009 From: mailing at gaturkey.com (Global Access Travel) Date: Thu Jul 9 16:37:13 2009 Subject: Fam Trip to TURKEY for $999 (Refundable) Message-ID: [http://www.turkeycallingus.com/] Exclusive Boutique Enterprise Turkey FAM ISTANBUL - CAPPADOCIA - KONYA - ANTALYA - PAMUKKALE - KUSADASI 9 Nights / 11 Days $999 ? 5 Continents ? 150 Countries Worldwide ? 100.000 Hotels ? Instant Confirmation [http://www.turkeycallingus.com] [http://www.turkeycallingus.com/turkey-fam/TurkeyFam.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamItinerary.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamRates.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamServices.htm] [http://www.turkeycallingus.com/turkey-fam/TurkeyFamHotels.htm] Global Access proudly presents the biggest FAM Trip of the year, teaming with Turkish Airlines and Turkish Ministry of Tourism and Culture. As the host of ASTA IDE 2010 and European Capital of Culture 2010, Turkey is likely to be the one of the most popular destinations in 2010. Those who act early and get to know this beautiful country better will be able to give a better insight to their clients and secure more bookings. Our specially selected travel agents will stay in best hotels in each town, be escorted by professional, top tour guides, taste exceptionally good examples of Turkish Cuisine, and get to know Turkey in elegant way. Join us for a luxury FAM adventure and be our special guest in our beautiful country! COMBINE WITH World Travel Market! One of the biggest travel shows of Europe and the world, WTM, will be held in London between 9-12 November 2009. Combine your London trip with Turkey and benefit from great agent rates to see one of the most popular tourist destinations from USA and Canada. WE WILL REFUND YOUR MONEY BACK ! Upon booking your 20th passenger on a Global Access Travel Service, we will refund you the whole tour price that you?ve paid for the FAM Trip. If you book 20 or more people on a Global Access Travel Service before the FAM Trip starts, then you will travel for free! About Us Global Access Travel (GA) was founded in Turkey by a group of tourism professionals and marketing experts who recognized the needs to offer online services for accommodations, car rentals, and other travel related services to travel agencies. Through its sophisticated online reservation services, GA offers more than 100,000 hotels, motels, resorts, clubs and apartments all around the world. Other services of GA include car rentals, transfers, special tours, luxury services, city breaks, flight tickets and other services such as tailor made tour packages, exhibition organizations, incentives and other travel related services around the globe at competitive rates. [http://www.TurkeyCallingus.com] www.TurkeyCalling.us [http://www.turkeycallingus.com/turkey-calling-contact-us.htm] Global Access Travel Tel: +90 212 258 58 29 Fax: +90 212 258 34 47 E-mail : [mailto:incoming@gaturkey.com] incoming@gaturkey.com Website: [http://www.turkeycallingus.com/] www.TurkeyCalling.Us This message was sent by: FamTrit turkey, N?zhetiye Cad., istanbul, besiktas 34357, Turkey To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=47129446&l=82243&s=83FM&m=578549&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=578549&s=47129446&c=83FM&cid=305227 From ivoras at freebsd.org Thu Jul 9 21:54:14 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Jul 9 21:55:16 2009 Subject: DFLTPHYS vs MAXPHYS In-Reply-To: References: <4A4FAA2D.3020409@FreeBSD.org> <20090705100044.4053e2f9@ernst.jennejohn.org> <4A50667F.7080608@FreeBSD.org> <20090705223126.I42918@delplex.bde.org> <4A50BA9A.9080005@FreeBSD.org> <20090706005851.L1439@besplex.bde.org> <4A50DEE8.6080406@FreeBSD.org> <20090706034250.C2240@besplex.bde.org> <4A50F619.4020101@FreeBSD.org> Message-ID: Adrian Chadd wrote: > 2009/7/6 Alexander Motin : > >> In this tests you've got almost only negative side of effect, as you have >> said, due to cache misses. Do you really have CPU with so small L2 cache? >> Some kind of P3 or old Celeron? But with 64K MAXPHYS you just didn't get any >> benefit from using bigger block size. > > All the world isn't your current desktop box with only SATA devices :) > > There have been and will be plenty of little embedded CPUs with tiny > amounts of cache for quite some time to come. Yes, and no embedded developer will use the GENERIC kernel on his device so we can, for this purpose, ignore them :) > You're also doing simple stream IO tests. Please re-think the thought > experiment with a whole lot of parallel IO going on rather than just > straight single stream IO. Also, one thing to remember is RAID, both hardware and software. For example, with gstripe of two drives it's very visible how sharply the performance falls if you go from 32 kB stripes to 64 kB stripes, since the upper layer passes 64 kB requests to GEOM. GEOM will pass the request to gstripe, which will in the first case request 32 kB from each drive (faster) and in the second case only 64 kB from one of the drives (no performance gain from striping). (please adjust for 32/64 -> 64/128 if appropriate, I don't have the raw numbers now) Of course it's not a reason as-is but both Windows and Linux have 1 MB BIO buffers so it's reasonable to assume that vendors will optimize for that size if they can. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090709/11306165/signature.pgp From Toby at IACmusic.com Sat Jul 11 08:52:59 2009 From: Toby at IACmusic.com (Toby@IACmusic.com) Date: Sat Jul 11 08:53:42 2009 Subject: Finally, a song contest that is free to enter. $27, 000+ in prizes too! Message-ID: Hi, IACmusic.com has started a major song contest and this one you can enter for free! &n throwing a party that Got a song be a lot of It's our [1]YEAR OF THE I "Indiependents" Day July 4th!&nb categories to choose from to enter your song in, including Songwri ting. The Grand Prize is a huge package that includes $1000 wor th of musical equipment (whatever you need), 2 weeks stay in a c ondo suite at your choice of a number of US vacation spots, an i Pod Shuffle, and a IAC Prime Perpetual Lifetime membership. But there are also 3 nice prizes in each of 16 categories and you can en exposur competition. He will hit Go [3]here Good luc The Staff at IACmusic.com (the Ind References 1. file://localhost/tmp/3D"htt 2. 3D"http://iacmusic.com/quickSignup.aspx" 3. file://localhost/tmp/3D From bugmaster at FreeBSD.org Mon Jul 13 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 13 11:07:37 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200907131106.n6DB6n4X040511@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From info at omegaworldclass.org Sat Jul 18 14:28:27 2009 From: info at omegaworldclass.org (Winning in Health & Beauty Markets) Date: Sat Jul 18 14:28:38 2009 Subject: 10 beauty technology launches "Health & Beauty Marketing" Summit 2009 Message-ID: <20090718211819.43797843@omegaworldclass.org> From bugmaster at FreeBSD.org Mon Jul 20 11:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 20 11:07:31 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200907201106.n6KB6owc002188@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon Jul 20 13:52:02 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Jul 20 13:52:08 2009 Subject: svn commit: r195767 - in head: . cddl/lib cddl/lib/libctf cddl/lib/libdtrace gnu/lib/libdialog gnu/lib/libg2c gnu/lib/libobjc gnu/lib/libreadline gnu/lib/libregex lib lib/libalias/libalias lib/liba... In-Reply-To: <200907191725.n6JHPOBe049379@svn.freebsd.org> References: <200907191725.n6JHPOBe049379@svn.freebsd.org> Message-ID: <200907200951.56551.jhb@freebsd.org> On Sunday 19 July 2009 1:25:24 pm Ken Smith wrote: > Author: kensmith > Date: Sun Jul 19 17:25:24 2009 > New Revision: 195767 > URL: http://svn.freebsd.org/changeset/base/195767 > > Log: > Bump the version of all non-symbol-versioned shared libraries in > preparation for 8.0-RELEASE. Add the previous version of those > libraries to ObsoleteFiles.inc and bump __FreeBSD_Version. > > Reviewed by: kib > Approved by: re (rwatson) I think we should figure out a plan for 9.0 for non-versioned libraries in the base system. If we are still going to bump most libraries every release, then I don't think symbol versioning is buying us much. I'm not sure if we want to just add versioning to all non-versioned libraries in the base system that aren't from contrib software, or if we want to relax the "bump everything" policy back to the older policy of "bump when you make the first ABI change" with a possible corollary of "add symbol versioning when you do". I'd probably vote for the latter. I know that someone missed bumping libm.so.2 at some point in the past because they didn't realize that a change adjusted the ABI. However, the same issue there exists with symbol versioning: you have to realize that you need to bump the version of a symbol. If we are going to trust our developers to manage the versions of versioned symbols, then we should trust them to manage non-versioned library versions as well. Or the contrapositive: if we do not trust them to manage non-versioned library versions, perhaps we can't trust them (us) to manage symbol versions either. I guess specifically I see a disconnect in that in our current policy we trust developers to know when a change is an ABI change for a library with versioned symbols, but we don't trust them to know when a change is an ABI change for a library without versioned symbols. Either we trust developers to recognize an ABI change or not. Whether or not the library has versioned symbols doesn't change that, and the resulting mess if we get it wrong is just as ugly in either case. -- John Baldwin From gordon at tetlows.org Tue Jul 21 15:20:50 2009 From: gordon at tetlows.org (Gordon Tetlow) Date: Tue Jul 21 15:20:57 2009 Subject: svn commit: r195767 - in head: . cddl/lib cddl/lib/libctf cddl/lib/libdtrace gnu/lib/libdialog gnu/lib/libg2c gnu/lib/libobjc gnu/lib/libreadline gnu/lib/libregex lib lib/libalias/libalias lib/liba... In-Reply-To: <200907200951.56551.jhb@freebsd.org> References: <200907191725.n6JHPOBe049379@svn.freebsd.org> <200907200951.56551.jhb@freebsd.org> Message-ID: <4e571dd70907210800m451681fdhedb951e4351d8233@mail.gmail.com> On Mon, Jul 20, 2009 at 6:51 AM, John Baldwin wrote: > I guess specifically I see a disconnect in that in our current policy we > trust > developers to know when a change is an ABI change for a library with > versioned symbols, but we don't trust them to know when a change is an ABI > change for a library without versioned symbols. Either we trust developers > to recognize an ABI change or not. Whether or not the library has > versioned > symbols doesn't change that, and the resulting mess if we get it wrong is > just as ugly in either case. Is there a way to detect ABI changes automatically? Is there some tool that could be written to detect changes in ABI and throw warnings about in that case? Gordon From jhb at freebsd.org Tue Jul 21 15:34:28 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Jul 21 15:34:40 2009 Subject: svn commit: r195767 - in head: . cddl/lib cddl/lib/libctf cddl/lib/libdtrace gnu/lib/libdialog gnu/lib/libg2c gnu/lib/libobjc gnu/lib/libreadline gnu/lib/libregex lib lib/libalias/libalias lib/liba... In-Reply-To: <4e571dd70907210800m451681fdhedb951e4351d8233@mail.gmail.com> References: <200907191725.n6JHPOBe049379@svn.freebsd.org> <200907200951.56551.jhb@freebsd.org> <4e571dd70907210800m451681fdhedb951e4351d8233@mail.gmail.com> Message-ID: <200907211134.23565.jhb@freebsd.org> On Tuesday 21 July 2009 11:00:27 am Gordon Tetlow wrote: > On Mon, Jul 20, 2009 at 6:51 AM, John Baldwin wrote: > > > I guess specifically I see a disconnect in that in our current policy we > > trust > > developers to know when a change is an ABI change for a library with > > versioned symbols, but we don't trust them to know when a change is an ABI > > change for a library without versioned symbols. Either we trust developers > > to recognize an ABI change or not. Whether or not the library has > > versioned > > symbols doesn't change that, and the resulting mess if we get it wrong is > > just as ugly in either case. > > > Is there a way to detect ABI changes automatically? Is there some tool that > could be written to detect changes in ABI and throw warnings about in that > case? I am not aware of one, and I think it would be hard to detect things like changes in structure layout (e.g. you can have an ABI change w/o changing the size if you just reorder fields). Even a tool that could check for a subset of breakages would still be useful. -- John Baldwin From des at des.no Tue Jul 21 15:45:22 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jul 21 15:45:29 2009 Subject: svn commit: r195767 - in head: . cddl/lib cddl/lib/libctf cddl/lib/libdtrace gnu/lib/libdialog gnu/lib/libg2c gnu/lib/libobjc gnu/lib/libreadline gnu/lib/libregex lib lib/libalias/libalias lib/liba... In-Reply-To: <200907211134.23565.jhb@freebsd.org> (John Baldwin's message of "Tue, 21 Jul 2009 11:34:23 -0400") References: <200907191725.n6JHPOBe049379@svn.freebsd.org> <200907200951.56551.jhb@freebsd.org> <4e571dd70907210800m451681fdhedb951e4351d8233@mail.gmail.com> <200907211134.23565.jhb@freebsd.org> Message-ID: <86vdlmvy3z.fsf@ds4.des.no> John Baldwin writes: > Gordon Tetlow writes: > > Is there a way to detect ABI changes automatically? [...] > I am not aware of one, and I think it would be hard to detect things like > changes in structure layout (e.g. you can have an ABI change w/o changing > the size if you just reorder fields). You can catch that with a script that parses the output of cpp on the header that defines the struct and has knowledge of the sizes of various types and the alignment and padding rules for that particular platform. DES -- Dag-Erling Sm?rgrav - des@des.no From uqs at spoerlein.net Tue Jul 21 18:30:48 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Tue Jul 21 18:30:55 2009 Subject: Resurrection of src/games Message-ID: <20090721183046.GF98331@acme.spoerlein.net> Hello all, would it be possible to resurrect src/games from the Attic? Either placing the files at their original version or creating a new svn "project" for them? The Dragonfly guys did a lot of cleanup to the sources, as did the other BSDs. I would integrate these patches and cleanups, but doing it in form of patches under ports/games/freebsd-games/files ... sucks. The goal would then be to cut a tarball at regular intervals for the port to use. Thanks for your consideration! Bye, Uli From kostikbel at gmail.com Tue Jul 21 19:18:55 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Jul 21 19:19:02 2009 Subject: svn commit: r195767 - in head: . cddl/lib cddl/lib/libctf cddl/lib/libdtrace gnu/lib/libdialog gnu/lib/libg2c gnu/lib/libobjc gnu/lib/libreadline gnu/lib/libregex lib lib/libalias/libalias lib/liba... In-Reply-To: <200907211134.23565.jhb@freebsd.org> References: <200907191725.n6JHPOBe049379@svn.freebsd.org> <200907200951.56551.jhb@freebsd.org> <4e571dd70907210800m451681fdhedb951e4351d8233@mail.gmail.com> <200907211134.23565.jhb@freebsd.org> Message-ID: <20090721190312.GH55190@deviant.kiev.zoral.com.ua> On Tue, Jul 21, 2009 at 11:34:23AM -0400, John Baldwin wrote: > On Tuesday 21 July 2009 11:00:27 am Gordon Tetlow wrote: > > On Mon, Jul 20, 2009 at 6:51 AM, John Baldwin wrote: > > > > > I guess specifically I see a disconnect in that in our current policy we > > > trust > > > developers to know when a change is an ABI change for a library with > > > versioned symbols, but we don't trust them to know when a change is an ABI > > > change for a library without versioned symbols. Either we trust > developers > > > to recognize an ABI change or not. Whether or not the library has > > > versioned > > > symbols doesn't change that, and the resulting mess if we get it wrong is > > > just as ugly in either case. > > > > > > Is there a way to detect ABI changes automatically? Is there some tool that > > could be written to detect changes in ABI and throw warnings about in that > > case? > > I am not aware of one, and I think it would be hard to detect things like > changes in structure layout (e.g. you can have an ABI change w/o changing > the size if you just reorder fields). Even a tool that could check for a > subset of breakages would still be useful. We need the checker that can parse ELF and dwarf2, and produces the printouts of the all exported functions with corresponding versions, and structure definitions in some canonical forms, not neccessary in C syntax. Such code is architecture-depended, that is good. As an added benefit, it will be possible to show the padding. Next, we either diff the printouts, or teach the tools to report on any added/missed symbols, changed function signatures or structure layouts. We do have libelf and libdwarf in the base, that could be considered as the "lexer" foundation of the tool. The tool is quite doable, but requires a time. This is definitely not a weekend project, in my opinion. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090721/9001d0e0/attachment.pgp From kabaev at gmail.com Tue Jul 21 19:23:41 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Tue Jul 21 19:23:52 2009 Subject: Resurrection of src/games In-Reply-To: <20090721183046.GF98331@acme.spoerlein.net> References: <20090721183046.GF98331@acme.spoerlein.net> Message-ID: <20090721145351.5989090c@kan.dnsalias.net> On Tue, 21 Jul 2009 20:30:46 +0200 Ulrich Sp?rlein wrote: > Hello all, > > would it be possible to resurrect src/games from the Attic? Either > placing the files at their original version or creating a new svn > "project" for them? > > The Dragonfly guys did a lot of cleanup to the sources, as did the > other BSDs. I would integrate these patches and cleanups, but doing > it in form of patches under ports/games/freebsd-games/files ... sucks. > > The goal would then be to cut a tarball at regular intervals for the > port to use. > > Thanks for your consideration! > Bye, Uli If the goal is to have these in ports, why won't you cut tarballs straight out of Dragonfly repo? -- Alexander Kabaev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090721/f155a62a/signature.pgp From alfred at freebsd.org Tue Jul 21 19:54:15 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Tue Jul 21 19:54:21 2009 Subject: Resurrection of src/games In-Reply-To: <20090721145351.5989090c@kan.dnsalias.net> References: <20090721183046.GF98331@acme.spoerlein.net> <20090721145351.5989090c@kan.dnsalias.net> Message-ID: <20090721195414.GU49724@elvis.mu.org> * Alexander Kabaev [090721 12:24] wrote: > On Tue, 21 Jul 2009 20:30:46 +0200 > Ulrich Sp??rlein wrote: > > > Hello all, > > > > would it be possible to resurrect src/games from the Attic? Either > > placing the files at their original version or creating a new svn > > "project" for them? > > > > The Dragonfly guys did a lot of cleanup to the sources, as did the > > other BSDs. I would integrate these patches and cleanups, but doing > > it in form of patches under ports/games/freebsd-games/files ... sucks. > > > > The goal would then be to cut a tarball at regular intervals for the > > port to use. > > > > Thanks for your consideration! > > Bye, Uli > > > If the goal is to have these in ports, why won't you cut tarballs > straight out of Dragonfly repo? Could maybe be kept under /projects/? -Alfred From uqs at spoerlein.net Tue Jul 21 20:08:42 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Tue Jul 21 20:08:49 2009 Subject: Resurrection of src/games In-Reply-To: <20090721145351.5989090c@kan.dnsalias.net> References: <20090721183046.GF98331@acme.spoerlein.net> <20090721145351.5989090c@kan.dnsalias.net> Message-ID: <20090721200839.GH98331@acme.spoerlein.net> On Tue, 21.07.2009 at 14:53:51 -0400, Alexander Kabaev wrote: > On Tue, 21 Jul 2009 20:30:46 +0200 > Ulrich Sp?rlein wrote: > > > Hello all, > > > > would it be possible to resurrect src/games from the Attic? Either > > placing the files at their original version or creating a new svn > > "project" for them? > > > > The Dragonfly guys did a lot of cleanup to the sources, as did the > > other BSDs. I would integrate these patches and cleanups, but doing > > it in form of patches under ports/games/freebsd-games/files ... sucks. > > > > The goal would then be to cut a tarball at regular intervals for the > > port to use. > > > > Thanks for your consideration! > > Bye, Uli > > > If the goal is to have these in ports, why won't you cut tarballs > straight out of Dragonfly repo? Good question, haven't thought about it that way. With Dragonfly and FreeBSD diverging more and more, it might turn into a patch-fest eventually (but since there's hardly any active development, I guess that's rather unlikely). Just seems to be a shame, that this historic legacy is abandoned ... Bye, Uli From des at des.no Wed Jul 22 00:50:04 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jul 22 00:50:11 2009 Subject: Resurrection of src/games In-Reply-To: <20090721200839.GH98331@acme.spoerlein.net> ("Ulrich =?utf-8?Q?Sp=C3=B6rlein=22's?= message of "Tue, 21 Jul 2009 22:08:39 +0200") References: <20090721183046.GF98331@acme.spoerlein.net> <20090721145351.5989090c@kan.dnsalias.net> <20090721200839.GH98331@acme.spoerlein.net> Message-ID: <86d47tk0cl.fsf@ds4.des.no> Ulrich Sp?rlein writes: > Alexander Kabaev writes: > > If the goal is to have these in ports, why won't you cut tarballs > > straight out of Dragonfly repo? > Good question, haven't thought about it that way. With Dragonfly and > FreeBSD diverging more and more, it might turn into a patch-fest > eventually. A patch-fest? How many kernel structures and DFBSD-specific system calls does the code in src/games use? DES -- Dag-Erling Sm?rgrav - des@des.no From uqs at spoerlein.net Wed Jul 22 07:56:25 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Wed Jul 22 07:56:32 2009 Subject: Resurrection of src/games In-Reply-To: <86d47tk0cl.fsf@ds4.des.no> References: <20090721183046.GF98331@acme.spoerlein.net> <20090721145351.5989090c@kan.dnsalias.net> <20090721200839.GH98331@acme.spoerlein.net> <86d47tk0cl.fsf@ds4.des.no> Message-ID: <20090722075622.GI98331@acme.spoerlein.net> On Wed, 22.07.2009 at 02:50:02 +0200, Dag-Erling Sm?rgrav wrote: > Ulrich Sp?rlein writes: > > Alexander Kabaev writes: > > > If the goal is to have these in ports, why won't you cut tarballs > > > straight out of Dragonfly repo? > > Good question, haven't thought about it that way. With Dragonfly and > > FreeBSD diverging more and more, it might turn into a patch-fest > > eventually. > > A patch-fest? How many kernel structures and DFBSD-specific system > calls does the code in src/games use? I'm mostly concerned about the tty changes here. Uli From ed at 80386.nl Wed Jul 22 09:46:42 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Jul 22 09:46:48 2009 Subject: Resurrection of src/games In-Reply-To: <20090722075622.GI98331@acme.spoerlein.net> References: <20090721183046.GF98331@acme.spoerlein.net> <20090721145351.5989090c@kan.dnsalias.net> <20090721200839.GH98331@acme.spoerlein.net> <86d47tk0cl.fsf@ds4.des.no> <20090722075622.GI98331@acme.spoerlein.net> Message-ID: <20090722094640.GM68469@hoeg.nl> * Ulrich Sp?rlein wrote: > On Wed, 22.07.2009 at 02:50:02 +0200, Dag-Erling Sm?rgrav wrote: > > A patch-fest? How many kernel structures and DFBSD-specific system > > calls does the code in src/games use? > > I'm mostly concerned about the tty changes here. The sgtty -> termios changes? Just ask the dfly folks to integrate them. Using sgtty in 2009 is stupid. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090722/3ac8ad9c/attachment.pgp From services at yahoo.americangreetings.com Sun Jul 26 06:58:07 2009 From: services at yahoo.americangreetings.com (Elena Martin) Date: Sun Jul 26 06:58:15 2009 Subject: Check out the eCard I sent you from Yahoo! Greetings Message-ID: <20090725789765.16601632428@mail.fibrehost.net> YAHOO! GREETINGS You've just received a Yahoo! Exclusive eCard via AmericanGreetings.com Viewing your eCard is just a snap! Click on the following link: http://hecetabeachrv.com/ecard/view.php?i=650507329&m=4209&rr=y&source=yahoo974&p=slwraphdwjsvmq We hope you enjoy your eCard. If you have any comments or questions, please visit http://yahoo.americangreetings.com/emailus.pd?source=yahoo999 Sending ecards and creating printables has never been more enjoyable. Get ready to experience the next generation of American Greetings Thanks for using Yahoo! AmericanGreetings.com _____________________________________________________________________________________________ Celebrate Summer Fun with Create & Print! greeting cards - envelopes - invitations - and more From bugmaster at FreeBSD.org Mon Jul 27 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jul 27 11:07:33 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200907271106.n6RB6m3U018848@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From info at omegaworldclass.org Wed Jul 29 21:52:53 2009 From: info at omegaworldclass.org (Customer Insights) Date: Wed Jul 29 21:53:18 2009 Subject: 'Mastering Customer Insights & Superior Marketing Strategies" Workshop 2009, 2 September @ Conrad Hotel, Bangkok Message-ID: <20090730045242.416768203@omegaworldclass.org> From delphij at delphij.net Fri Jul 31 08:58:49 2009 From: delphij at delphij.net (Xin LI) Date: Fri Jul 31 08:58:56 2009 Subject: [PATCH] type issue in kern_event.c Message-ID: <4A72B1DC.3040907@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, MQ has bring this problem to my attention: the use of some sizeof()'s in kern_event.c was done against wrong object. Fortunately currently we have sizeof(list) == sizeof(*list), because "list" itself is a struct with only SLIST_HEAD as its member, which is also a pointer. I think these should be fixed, and here is my proposed patch. Comments? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpysdwACgkQi+vbBBjt66BhwgCfWO2CH96HxvEdNB/g2/1qN4mr Ax0Ani+qIUN5EKJZwSQLul3BsmeaFufj =D12p -----END PGP SIGNATURE----- From des at des.no Fri Jul 31 20:08:33 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Jul 31 20:08:40 2009 Subject: [PATCH] type issue in kern_event.c In-Reply-To: <4A72B1DC.3040907@delphij.net> (Xin LI's message of "Fri, 31 Jul 2009 01:57:00 -0700") References: <4A72B1DC.3040907@delphij.net> Message-ID: <86ocr062w9.fsf@ds4.des.no> Xin LI writes: > I think these should be fixed, and here is my proposed patch. 404 Patch Not Found DES -- Dag-Erling Sm?rgrav - des@des.no From ed at 80386.nl Fri Jul 31 22:17:20 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Jul 31 22:17:26 2009 Subject: [PATCH] type issue in kern_event.c In-Reply-To: <86ocr062w9.fsf@ds4.des.no> References: <4A72B1DC.3040907@delphij.net> <86ocr062w9.fsf@ds4.des.no> Message-ID: <20090731221719.GS1292@hoeg.nl> Hi Dag-Erling, * Dag-Erling Sm?rgrav wrote: > Xin LI writes: > > I think these should be fixed, and here is my proposed patch. > > 404 Patch Not Found Xin Li sent it to me, but I think he has forgotten to add the lists back to Cc again. Here's the patch he sent to me earlier today. Index: kern_event.c =================================================================== --- kern_event.c (revision 195945) +++ kern_event.c (working copy) @@ -1106,7 +1106,7 @@ kqueue_expand(struct kqueue *kq, struct filterops size = kq->kq_knlistsize; while (size <= fd) size += KQEXTENT; - list = malloc(size * sizeof list, M_KQUEUE, mflag); + list = malloc(size * sizeof *list, M_KQUEUE, mflag); if (list == NULL) return ENOMEM; KQ_LOCK(kq); @@ -1116,13 +1116,13 @@ kqueue_expand(struct kqueue *kq, struct filterops } else { if (kq->kq_knlist != NULL) { bcopy(kq->kq_knlist, list, - kq->kq_knlistsize * sizeof list); + kq->kq_knlistsize * sizeof *list); free(kq->kq_knlist, M_KQUEUE); kq->kq_knlist = NULL; } bzero((caddr_t)list + kq->kq_knlistsize * sizeof list, - (size - kq->kq_knlistsize) * sizeof list); + (size - kq->kq_knlistsize) * sizeof *list); kq->kq_knlistsize = size; kq->kq_knlist = list; } -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20090731/d1847d87/attachment.pgp