[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#607327: marked as done (mount: Performance issues with losetup (and therefore XEN))

Your message dated Fri, 23 Apr 2021 10:18:03 +0200
with message-id <[🔎] YIKCu6WKd4KnyBbv@eldamar.lan>
and subject line Re: Bug#607327: mount: Performance issues with losetup (and therefore XEN)
has caused the Debian Bug report #607327,
regarding mount: Performance issues with losetup (and therefore XEN)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
607327: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607327
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: mount
Version: 2.17.2-3.3
Severity: important

Hello all,

I'm currently playing with xen and some intensive parallel I/O requests on disks.
I've remark some performance issues on XEN bring by losetup which drop the NCQ/TCQ/Queuing functionnality (which is really useful in parallel random access disk)

I'm using this C program to measure the performance impact : http://box.houkouonchi.jp/seeker_baryluk.c (found on this website : http://www.linuxinsight.com/how_fast_is_your_disk.html )

Please find some benchmark :

Performance of /dev/dm-2 (lvm) with 1 thread : 210 seeks/secs
root@srv-xen1:~# ./seeker_baryluk /dev/dm-2 1
[1 threads]
Results: 210 seeks/second, 4.755 ms random access time (33493245 < offsets < 60740308117)

Performance of /dev/dm-2 with 32 threads : 699 seeks/secs (at least 3x times better)
root@srv-xen1:~# ./seeker_baryluk /dev/dm-2 32
[32 threads]
Results: 699 seeks/second, 1.430 ms random access time (8670248 < offsets < 60740120558)

We are mapping /dev/dm-2 on /dev/loop0 (Yes, just a mapping of LVM drive without any FS interaction)
root@srv-xen1:~# losetup /dev/loop0 /dev/dm-2 

Performance of /dev/loop0 with 1 thread : exactly the same performance as direct random seek (good point here)
root@srv-xen1:~# ./seeker_baryluk /dev/loop0 1
[1 threads]
Results: 210 seeks/second, 4.757 ms random access time (4255332 < offsets < 60739140845)

Performance of /dev/loop0 with 32 threads : 211 seeks/mins <- Here we have "catastrophic" performance issues because we completly lost performance bring by NCQ/TCQ/Queuing !!
root@srv-xen1:~# ./seeker_baryluk /dev/loop0 32
[32 threads]
Results: 211 seeks/second, 4.735 ms random access time (14948337 < offsets < 60737675221)


Best regards,

Grégory



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_LU.UTF-8, LC_CTYPE=fr_LU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mount depends on:
ii  libblkid1                     2.17.2-3.3 block device id library
ii  libc6                         2.11.2-7   Embedded GNU C Library: Shared lib
ii  libselinux1                   2.0.96-1   SELinux runtime shared libraries
ii  libsepol1                     2.0.41-1   SELinux library for manipulating b
ii  libuuid1                      2.17.2-3.3 Universally Unique ID library

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common                    1:1.2.2-4  NFS support files common to client

-- no debconf information

--- End Message ---
--- Begin Message --- 
Control: tags -1 + moreinfo

Hi,

On Fri, Dec 17, 2010 at 02:04:01AM +0100, Gregory Auzanneau wrote:
> Package: mount
> Version: 2.17.2-3.3
> Severity: important
> 
> Hello all,
> 
> I'm currently playing with xen and some intensive parallel I/O requests on disks.
> I've remark some performance issues on XEN bring by losetup which drop the NCQ/TCQ/Queuing functionnality (which is really useful in parallel random access disk)
> 
> I'm using this C program to measure the performance impact : http://box.houkouonchi.jp/seeker_baryluk.c (found on this website : http://www.linuxinsight.com/how_fast_is_your_disk.html )
> 
> Please find some benchmark :
> 
> Performance of /dev/dm-2 (lvm) with 1 thread : 210 seeks/secs
> root@srv-xen1:~# ./seeker_baryluk /dev/dm-2 1
> [1 threads]
> Results: 210 seeks/second, 4.755 ms random access time (33493245 < offsets < 60740308117)
> 
> Performance of /dev/dm-2 with 32 threads : 699 seeks/secs (at least 3x times better)
> root@srv-xen1:~# ./seeker_baryluk /dev/dm-2 32
> [32 threads]
> Results: 699 seeks/second, 1.430 ms random access time (8670248 < offsets < 60740120558)
> 
> We are mapping /dev/dm-2 on /dev/loop0 (Yes, just a mapping of LVM drive without any FS interaction)
> root@srv-xen1:~# losetup /dev/loop0 /dev/dm-2 
> 
> Performance of /dev/loop0 with 1 thread : exactly the same performance as direct random seek (good point here)
> root@srv-xen1:~# ./seeker_baryluk /dev/loop0 1
> [1 threads]
> Results: 210 seeks/second, 4.757 ms random access time (4255332 < offsets < 60739140845)
> 
> Performance of /dev/loop0 with 32 threads : 211 seeks/mins <- Here we have "catastrophic" performance issues because we completly lost performance bring by NCQ/TCQ/Queuing !!
> root@srv-xen1:~# ./seeker_baryluk /dev/loop0 32
> [32 threads]
> Results: 211 seeks/second, 4.735 ms random access time (14948337 < offsets < 60737675221)

Assuming this is not reproducible (anymore), or is this still the
case? I'm for now closing the bugreport, please feel free to reopen in
case the issue could still be triggered.

Regards,
Salvatore

--- End Message ---
Reply to: