[Stgt-devel] No LUN option in target.c

[FUJITA Tomonori]

On Mon, 26 Nov 2007 15:53:37 +0100
Tomasz Chmielewski <mangoo at wpkg.org> wrote:

> FUJITA Tomonori schrieb:
> > On Mon, 26 Nov 2007 13:33:47 +0100
> > Tomasz Chmielewski <mangoo at wpkg.org> wrote:
> > 
> >> FUJITA Tomonori schrieb:
> >>> On Mon, 26 Nov 2007 12:25:19 +0100
> >>> Albert Pauw <albert.pauw at gmail.com> wrote:
> >>>
> >>>> 2007/11/26-12:24:19 | STAT  | 3237 | v1.2.8 | /dev/sdb | Total read 
> >>>> throughput: 827938.1B/s (0.79MB/s), IOPS 25.3/s.
> >>>>
> >>>> The patch didn't make a difference, sorry.
> >>> The performances in the configuration don't matter much, but I just
> >>> run initiator and target on the same machine:
> >>>
> >>> sens:/home/fujita# hdparm -t /dev/sdd
> >>>
> >>> /dev/sdd:
> >>>  Timing buffered disk reads:   20 MB in  3.15 seconds =   6.35 MB/sec
> >> (...)
> >>
> >>> sens:/home/fujita# hdparm -t /dev/sdd
> >>>
> >>> /dev/sdd:
> >>>  Timing buffered disk reads:  410 MB in  3.02 seconds = 135.55 MB/sec
> >>>
> >>>
> >>> Seems that haparm isn't an appropriate tool to meature performance but
> >>> not bad performances.
> >> It is appropriate, when used appropriately.
> > 
> > Oops, I'm not talking about only cache.
> > 
> > hdparm seems to issue only one outstanding request, the duration is
> > too short, etc. It's not designed for performance measurement.
> 
> True, hdparm is only a very basic tool for measuring performance.
> 
> 
> >> If a block device is used (mounted, swap, md/dm etc.) it is also cached.
> > 
> > Block devices always use page cache (unless you access to it via DIO).
> 
> Umm:
> 
> 
> # echo 3 > /proc/sys/vm/drop_caches
> 
> # free
>               total       used       free     shared    buffers     cached
> Mem:        512252      22152     490100          0         84       4320
> -/+ buffers/cache:      17748     494504
> Swap:            0          0          0
> 
> # dd if=/dev/LVM2/swap of=/dev/null
> 6291456+0 records in
> 6291456+0 records out
> 3221225472 bytes (3.2 GB) copied, 52.8739 seconds, 60.9 MB/s
> 
> # free
>               total       used       free     shared    buffers     cached
> Mem:        512252      22760     489492          0        124       4708
> -/+ buffers/cache:      17928     494324
> Swap:            0          0          0
> 
> So, nothing was cached.

When dd finished, nothing was cached. But dd enjoyed cache.

ag:/home/fujita# echo 3 > /proc/sys/vm/drop_caches
ag:/home/fujita# free
             total       used       free     shared    buffers     cached
Mem:        256696      32144     224552          0        188       4048
-/+ buffers/cache:      27908     228788
Swap:       409616          0     409616

ag:/home/fujita# dd if=/dev/sdb of=/dev/null

Let's suspend dd and see how memory is used:

[1]+  Stopped                 dd if=/dev/sdb of=/dev/null

ag:/home/fujita# free
             total       used       free     shared    buffers     cached
Mem:        256696      61408     195288          0      28144       4208
-/+ buffers/cache:      29056     227640
Swap:       409616          0     409616


'buffers' is the amount of page cache belonging to block devices. dd
use tons of page cache.

If dd reads a block device sequentially, probabaly dd can enjoy page
cache due to readahead.

So you never get proper results of disk performance with programs that
doesn't use dio.


> > BTW, please let me know if you find that tgt's performance is still
> > terrible as compared with IET.
> 
> Yes, I'll try to make some tests this week.

Nice, thanks.