| === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel | ||
| === ajmitch_ [n=ajmitch@port161-160.ubs.maxnet.co.nz] has joined #ubuntu-kernel | ||
| === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel | ||
| === psusi [n=phreak@54.161.205.68.cfl.res.rr.com] has joined #ubuntu-kernel | ||
| psusi | I'm seing some strange behavior in blockdev I think... dd is writing out data to a cdrw and it looks like blockdev is buffering up hundreds of megs of data | 06:12 |
|---|---|---|
| psusi | then dd says it hit the end of the device, and syncs, at which point it goes uninterruptable for 10 minutes while 300 MB of dirty buffers are flushed | 06:12 |
| psusi | this only happens though if I have dd use a large block size like 256 KiB, with the default 2 KiB blocksize, blockdev appears to not buffer so much | 06:13 |
| psusi | so dd reports a lower throughput midway through, but when it finally hits the end and syncs, it doesn't go uninterruptable for 10 minutes | 06:14 |
| psusi | why is the block layer so strange? ;) | 06:15 |
| BenC | psusi: buffering improves performance | 06:21 |
| BenC | most things don't call sync, so your problem is kind of unique to dd | 06:22 |
| psusi | BenC, yea... but only to a point... buffering 300 megs of sequential IO is a bit silly isn't it? and more importantly, why does it buffer more when dd is sending down larger write()s? | 06:27 |
| BenC | how do you know it's 300megs? | 06:27 |
| psusi | with bs=2KiB it looks like the block layer is causing dd to sleep more to let the device catch up with the dirty buffer flushing | 06:27 |
| BenC | more transactions, so block layer is flushing more often | 06:28 |
| psusi | BenC, I'm guestimating because when dd goes to sync, the process goes uninterruptable in the sync for 10 minutes while the rest of the dirty buffers are actually written | 06:28 |
| BenC | how much mem/swap do you have? | 06:28 |
| psusi | why does the number of transactions do anything? shouldn't the block layer see that there is already plenty of dirty buffers queued to the device waiting to be flushed adn block untill some of those complete? regardless of block size | 06:29 |
| psusi | gig of ram | 06:29 |
| BenC | probably a better question for the kernel devs | 06:30 |
| BenC | people familiar with the vm/block layers | 06:30 |
| psusi | I suppose the buffering is good for apps that don't sync.... I guess what I don't like is that the sync goes uninterruptable for 10 minutes | 06:31 |
| psusi | I need to clean up my aio dd patches and get them submitted | 06:32 |
| psusi | aio avoids the D state which is nice | 06:32 |
| psusi | of course, the drastically lower cpu load and somewhat higher throughput are nice too ;) | 06:32 |
| BenC | do you really want to interrupt a sync()? :) | 06:36 |
| psusi | I really want the process to die when I send it a SIGKILL ;) | 06:40 |
| === j_ack [n=nico@p508D8901.dip0.t-ipconnect.de] has joined #ubuntu-kernel | ||
| === fabbione [n=fabbione@82.109.136.125] has joined #ubuntu-kernel | ||
| === JaneW [n=JaneW@82.109.136.125] has joined #ubuntu-kernel | ||
| === doko [n=doko@82.109.136.125] has joined #ubuntu-kernel | ||
| === mjg59 [n=mjg59@cavan.codon.org.uk] has joined #ubuntu-kernel | ||
| === sn9 [n=danielg4@gimpelevich.san-francisco.ca.us] has joined #ubuntu-kernel | ||
| === doko_ [n=doko@82.109.136.125] has joined #ubuntu-kernel | ||
| === doko_ [n=doko@82.109.136.125] has joined #ubuntu-kernel | ||
| === fabbione_ [n=fabbione@82.109.136.125] has joined #ubuntu-kernel | ||
| === jane_ [n=JaneW@82.109.136.125] has joined #ubuntu-kernel | ||
| === doko [n=doko@82.109.136.125] has joined #ubuntu-kernel | ||
| === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel | ||
| zul | heylo | 05:38 |
| === doko [n=doko@82.109.136.125] has joined #ubuntu-kernel | ||
| === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel | ||
| === sn9 [n=danielg4@gimpelevich.san-francisco.ca.us] has joined #ubuntu-kernel | ||
| === lamont [n=upirc@67-135-65-162.dia.cust.qwest.net] has joined #ubuntu-kernel | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!