lkml.org 
[lkml]   [2009]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: I/O and pdflush
From
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!

One other idea is to ensure the filesystem starts on an (at least)
128KB boundary, so as to submit complete erase blocks (usually 128KB).

Thanks,
Daniel
--
Daniel J Blueman
--
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/

\
 
 \ /
  Last update: 2009-09-01 00:51    [W:0.027 / U:5.168 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site