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

[Ming Zhang]

On Tue, 2007-11-27 at 01:01 +0900, FUJITA Tomonori wrote:
> 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.


check if your dd version is new enough to support dio.

from dd man page.

       Each FLAG symbol may be:

       append append mode (makes sense only for output)

       direct use direct I/O for data



> 
> 
> > > 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.
> _______________________________________________
> Stgt-devel mailing list
> Stgt-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/stgt-devel
-- 
Ming Zhang


@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------