Messages in this thread | | | From | Fernando Silveira <> | Date | Tue, 1 Sep 2009 11:33:55 -0300 | Subject | Re: I/O and pdflush |
| |
On Mon, Aug 31, 2009 at 18:57, Daniel J Blueman<daniel.blueman@gmail.com> wrote: > On Jul 11, 6:30 pm, Fernando Silveira <fsilve...@gmail.com> wrote: >> The problem is that after some time of data writing at 70MB/s, it >> eventually falls down to about 25MB/s and does not get up again until >> a loooong time has passed (from 1 to 30 minutes). This happens much >> more often when "vm.dirty_*" settings are default (30 secs to expire, >> 5 secs for writeback, 10% and 40% for background and normal ratio), >> and when I set them to 1 second or even 0, the problem happens much >> less often and the sticking period of 25MB/s is much lower. > [snip] > > Generally, this sounds symptomatic of the (now well-documented) > internal block management of the SSD delaying writes significantly > over long use periods - the output from eg 'vmstat 3' will show all > the time spent in I/O wait of course. > > In your case, the OCZ Core v2 SSD uses the famed JMicron JMF602 which > chokes up with outstanding write requests, destroying latency and > throughput with it. OCZ won't be releasing newer firmware for the Core > v2, so one last-ditch option is to install the newer stock (non-OCZ > validated, thus invalidating the warranty) JMicron firmware, which > alleviates this somewhat. I've found this successful, though it's > tricky to find!
Thanks, I'll keep that in mind. If no other safer solution else helps, I'll update the JMicron.
> One other idea is to ensure the filesystem starts on an (at least) > 128KB boundary, so as to submit complete erase blocks (usually 128KB).
I don't use any kind of filesystem, just plain sequential data dump. I can change the block size for each write(2), but I'm already using a huge one: 4MB. I tried lower and higher values before but it seems that the 70~80MB/s rate is only reached with blocks of 1MB or bigger.
-- Fernando Silveira <fsilveira@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |