* Weird trim test results
@ 2013-07-24 20:22 Matthew Eaton
2013-07-25 14:36 ` Jens Axboe
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Eaton @ 2013-07-24 20:22 UTC (permalink / raw)
To: fio
Hi guys,
I'm using this simple trim test on a raw SSD but getting very low
performance. Bandwidth seems to be tied to the block size. Am I
doing something wrong?
[trim]
rw=randtrim
bs=4k
ioengine=sync
filename=/dev/sdb
runtime=30
trim: (g=0): rw=randtrim, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1
fio-2.1
Starting 1 process
Jobs: 1 (f=1): [d] [100.0% done] [0KB/0KB/400KB /s] [0/0/100 iops] [eta 00m:00s]
trim: (groupid=0, jobs=1): err= 0: pid=4616: Wed Jul 24 12:54:10 2013
trim: io=11996KB, bw=409408B/s, iops=99, runt= 30004msec
clat (usec): min=4597, max=20401, avg=9999.91, stdev=431.52
lat (usec): min=4597, max=20401, avg=10000.15, stdev=431.53
clat percentiles (usec):
| 1.00th=[ 8768], 5.00th=[ 9920], 10.00th=[10048], 20.00th=[10048],
| 30.00th=[10048], 40.00th=[10048], 50.00th=[10048], 60.00th=[10048],
| 70.00th=[10048], 80.00th=[10048], 90.00th=[10048], 95.00th=[10048],
| 99.00th=[11328], 99.50th=[11328], 99.90th=[14912], 99.95th=[20096],
| 99.99th=[20352]
bw (KB /s): min= 385, max= 401, per=100.00%, avg=399.76, stdev= 1.99
lat (msec) : 10=84.06%, 20=15.87%, 50=0.07%
cpu : usr=0.11%, sys=0.12%, ctx=2999, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=0/d=2999, short=r=0/w=0/d=0
Run status group 0 (all jobs):
TRIM: io=11996KB, aggrb=399KB/s, minb=399KB/s, maxb=399KB/s,
mint=30004msec, maxt=30004msec
Disk stats (read/write):
sdb: ios=84/2988, merge=0/0, ticks=4/29832, in_queue=29840, util=99.47%
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird trim test results
2013-07-24 20:22 Weird trim test results Matthew Eaton
@ 2013-07-25 14:36 ` Jens Axboe
2013-07-25 17:27 ` Matthew Eaton
0 siblings, 1 reply; 6+ messages in thread
From: Jens Axboe @ 2013-07-25 14:36 UTC (permalink / raw)
To: Matthew Eaton; +Cc: fio
On 07/24/2013 02:22 PM, Matthew Eaton wrote:
> Hi guys,
>
> I'm using this simple trim test on a raw SSD but getting very low
> performance. Bandwidth seems to be tied to the block size. Am I
> doing something wrong?
What kernel are you on? This looks like a missing unplug issue. If you
run a blktrace for a few seconds while the test is ongoing, the output
of blkparse should reveal if you are seeing timer unplugs.
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird trim test results
2013-07-25 14:36 ` Jens Axboe
@ 2013-07-25 17:27 ` Matthew Eaton
2013-07-25 18:17 ` Jens Axboe
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Eaton @ 2013-07-25 17:27 UTC (permalink / raw)
To: Jens Axboe; +Cc: fio
Hi Jens,
I'm running Ubuntu 12.04.2, my kernel is:
Linux matt-work 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20
18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Here is the output I got from blktrace / blkparse:
Total (sdb):
Reads Queued: 166, 664KiB Writes Queued:
3001, 12004KiB
Read Dispatches: 166, 664KiB Write Dispatches:
3001, 12004KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 166, 664KiB Writes Completed:
3001, 1500KiB
Read Merges: 0, 0KiB Write Merges:
0, 0KiB
PC Reads Queued: 0, 0KiB PC Writes Queued:
0, 0KiB
PC Read Disp.: 22, 3KiB PC Write Disp.:
0, 0KiB
PC Reads Req.: 0 PC Writes Req.: 0
PC Reads Compl.: 10 PC Writes Compl.: 0
IO unplugs: 166 Timer unplugs: 0
On Thu, Jul 25, 2013 at 7:36 AM, Jens Axboe <axboe@kernel.dk> wrote:
> On 07/24/2013 02:22 PM, Matthew Eaton wrote:
>> Hi guys,
>>
>> I'm using this simple trim test on a raw SSD but getting very low
>> performance. Bandwidth seems to be tied to the block size. Am I
>> doing something wrong?
>
> What kernel are you on? This looks like a missing unplug issue. If you
> run a blktrace for a few seconds while the test is ongoing, the output
> of blkparse should reveal if you are seeing timer unplugs.
>
> --
> Jens Axboe
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird trim test results
2013-07-25 17:27 ` Matthew Eaton
@ 2013-07-25 18:17 ` Jens Axboe
2013-07-25 19:19 ` Matthew Eaton
0 siblings, 1 reply; 6+ messages in thread
From: Jens Axboe @ 2013-07-25 18:17 UTC (permalink / raw)
To: Matthew Eaton; +Cc: fio
Please don't top post...
On 07/25/2013 11:27 AM, Matthew Eaton wrote:
> Hi Jens,
>
> I'm running Ubuntu 12.04.2, my kernel is:
>
> Linux matt-work 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20
> 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>
> Here is the output I got from blktrace / blkparse:
>
> Total (sdb):
> Reads Queued: 166, 664KiB Writes Queued:
> 3001, 12004KiB
> Read Dispatches: 166, 664KiB Write Dispatches:
> 3001, 12004KiB
> Reads Requeued: 0 Writes Requeued: 0
> Reads Completed: 166, 664KiB Writes Completed:
> 3001, 1500KiB
> Read Merges: 0, 0KiB Write Merges:
> 0, 0KiB
> PC Reads Queued: 0, 0KiB PC Writes Queued:
> 0, 0KiB
> PC Read Disp.: 22, 3KiB PC Write Disp.:
> 0, 0KiB
> PC Reads Req.: 0 PC Writes Req.: 0
> PC Reads Compl.: 10 PC Writes Compl.: 0
> IO unplugs: 166 Timer unplugs: 0
That looks fine, it might just be coincidence that you are capped at
~100 IOPS. I don't think it's that unlikely that the this is the limit
for you, your device might have a fixed overhead associated with a trim
request. I'd have to look closer at your system to see if that's the
case or not.
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird trim test results
2013-07-25 18:17 ` Jens Axboe
@ 2013-07-25 19:19 ` Matthew Eaton
2013-07-25 19:19 ` Jens Axboe
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Eaton @ 2013-07-25 19:19 UTC (permalink / raw)
To: Jens Axboe; +Cc: fio
On Thu, Jul 25, 2013 at 11:17 AM, Jens Axboe <axboe@kernel.dk> wrote:
> Please don't top post...
>
> On 07/25/2013 11:27 AM, Matthew Eaton wrote:
>> Hi Jens,
>>
>> I'm running Ubuntu 12.04.2, my kernel is:
>>
>> Linux matt-work 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20
>> 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Here is the output I got from blktrace / blkparse:
>>
>> Total (sdb):
>> Reads Queued: 166, 664KiB Writes Queued:
>> 3001, 12004KiB
>> Read Dispatches: 166, 664KiB Write Dispatches:
>> 3001, 12004KiB
>> Reads Requeued: 0 Writes Requeued: 0
>> Reads Completed: 166, 664KiB Writes Completed:
>> 3001, 1500KiB
>> Read Merges: 0, 0KiB Write Merges:
>> 0, 0KiB
>> PC Reads Queued: 0, 0KiB PC Writes Queued:
>> 0, 0KiB
>> PC Read Disp.: 22, 3KiB PC Write Disp.:
>> 0, 0KiB
>> PC Reads Req.: 0 PC Writes Req.: 0
>> PC Reads Compl.: 10 PC Writes Compl.: 0
>> IO unplugs: 166 Timer unplugs: 0
>
> That looks fine, it might just be coincidence that you are capped at
> ~100 IOPS. I don't think it's that unlikely that the this is the limit
> for you, your device might have a fixed overhead associated with a trim
> request. I'd have to look closer at your system to see if that's the
> case or not.
>
> --
> Jens Axboe
>
Sorry, I'm kind of new to mailing lists. I'll test some different
drive / system configurations next. Thanks for your help!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Weird trim test results
2013-07-25 19:19 ` Matthew Eaton
@ 2013-07-25 19:19 ` Jens Axboe
0 siblings, 0 replies; 6+ messages in thread
From: Jens Axboe @ 2013-07-25 19:19 UTC (permalink / raw)
To: Matthew Eaton; +Cc: fio
On 07/25/2013 01:19 PM, Matthew Eaton wrote:
> On Thu, Jul 25, 2013 at 11:17 AM, Jens Axboe <axboe@kernel.dk> wrote:
>> Please don't top post...
>>
>> On 07/25/2013 11:27 AM, Matthew Eaton wrote:
>>> Hi Jens,
>>>
>>> I'm running Ubuntu 12.04.2, my kernel is:
>>>
>>> Linux matt-work 3.5.0-36-generic #57~precise1-Ubuntu SMP Thu Jun 20
>>> 18:21:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> Here is the output I got from blktrace / blkparse:
>>>
>>> Total (sdb):
>>> Reads Queued: 166, 664KiB Writes Queued:
>>> 3001, 12004KiB
>>> Read Dispatches: 166, 664KiB Write Dispatches:
>>> 3001, 12004KiB
>>> Reads Requeued: 0 Writes Requeued: 0
>>> Reads Completed: 166, 664KiB Writes Completed:
>>> 3001, 1500KiB
>>> Read Merges: 0, 0KiB Write Merges:
>>> 0, 0KiB
>>> PC Reads Queued: 0, 0KiB PC Writes Queued:
>>> 0, 0KiB
>>> PC Read Disp.: 22, 3KiB PC Write Disp.:
>>> 0, 0KiB
>>> PC Reads Req.: 0 PC Writes Req.: 0
>>> PC Reads Compl.: 10 PC Writes Compl.: 0
>>> IO unplugs: 166 Timer unplugs: 0
>>
>> That looks fine, it might just be coincidence that you are capped at
>> ~100 IOPS. I don't think it's that unlikely that the this is the limit
>> for you, your device might have a fixed overhead associated with a trim
>> request. I'd have to look closer at your system to see if that's the
>> case or not.
>>
>> --
>> Jens Axboe
>>
>
> Sorry, I'm kind of new to mailing lists. I'll test some different
> drive / system configurations next. Thanks for your help!
I think that would be useful, will certainly help in pin pointing what
the limiting component is here.
--
Jens Axboe
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-07-25 19:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-24 20:22 Weird trim test results Matthew Eaton
2013-07-25 14:36 ` Jens Axboe
2013-07-25 17:27 ` Matthew Eaton
2013-07-25 18:17 ` Jens Axboe
2013-07-25 19:19 ` Matthew Eaton
2013-07-25 19:19 ` Jens Axboe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.