* Performance Issues
@ 2014-09-19 12:18 Rob Spanton
2014-09-19 12:25 ` Swâmi Petaramesh
` (4 more replies)
0 siblings, 5 replies; 29+ messages in thread
From: Rob Spanton @ 2014-09-19 12:18 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 1431 bytes --]
Hi,
I have a particularly uncomplicated setup (a desktop PC with a hard
disk) and I'm seeing particularly slow performance from btrfs. A `git
status` in the linux source tree takes about 46 seconds after dropping
caches, whereas on other machines using ext4 this takes about 13s. My
mail client (evolution) also seems to perform particularly poorly on
this setup, and my hunch is that it's spending a lot of time waiting on
the filesystem.
I've tried mounting with noatime, and this has had no effect. Anyone
got any ideas?
Here are the things that the wiki page asked for [1]:
uname -a:
Linux zarniwoop.blob 3.16.2-200.fc20.x86_64 #1 SMP Mon Sep 8
11:54:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
btrfs --version:
Btrfs v3.16
btrfs fi show:
Label: 'fedora' uuid: 717c0a1b-815c-4e6a-86c0-60b921e84d75
Total devices 1 FS bytes used 1.49TiB
devid 1 size 2.72TiB used 1.50TiB path /dev/sda4
Btrfs v3.16
btrfs fi df /:
Data, single: total=1.48TiB, used=1.48TiB
System, DUP: total=32.00MiB, used=208.00KiB
Metadata, DUP: total=11.50GiB, used=10.43GiB
unknown, single: total=512.00MiB, used=0.00
dmesg dump is attached.
Please CC any responses to me, as I'm not subscribed to the list.
Cheers,
Rob
[1] https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list
[-- Attachment #1.2: dmesg.log --]
[-- Type: text/x-log, Size: 65704 bytes --]
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.16.2-200.fc20.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC) ) #1 SMP Mon Sep 8 11:54:45 UTC 2014
[ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.16.2-200.fc20.x86_64 root=UUID=717c0a1b-815c-4e6a-86c0-60b921e84d75 ro rootflags=subvol=root vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_GB.UTF-8
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009dbff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000dfedffff] usable
[ 0.000000] BIOS-e820: [mem 0x00000000dfee0000-0x00000000dfee2fff] ACPI NVS
[ 0.000000] BIOS-e820: [mem 0x00000000dfee3000-0x00000000dfeeffff] ACPI data
[ 0.000000] BIOS-e820: [mem 0x00000000dfef0000-0x00000000dfefffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000f0000000-0x00000000f3ffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000ffffffff] reserved
[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000019fffffff] usable
[ 0.000000] NX (Execute Disable) protection: active
[ 0.000000] SMBIOS 2.4 present.
[ 0.000000] DMI: Gigabyte Technology Co., Ltd. P35-S3G/P35-S3G, BIOS F5 06/19/2009
[ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[ 0.000000] e820: last_pfn = 0x1a0000 max_arch_pfn = 0x400000000
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-CDFFF write-protect
[ 0.000000] CE000-EFFFF uncachable
[ 0.000000] F0000-FFFFF write-through
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 000000000 mask F00000000 write-back
[ 0.000000] 1 base 0E0000000 mask FE0000000 uncachable
[ 0.000000] 2 base 100000000 mask F00000000 write-back
[ 0.000000] 3 base 1C0000000 mask FC0000000 uncachable
[ 0.000000] 4 base 1A0000000 mask FE0000000 uncachable
[ 0.000000] 5 base 0DFF00000 mask FFFF00000 uncachable
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] e820: update [mem 0xdff00000-0xffffffff] usable ==> reserved
[ 0.000000] e820: last_pfn = 0xdfee0 max_arch_pfn = 0x400000000
[ 0.000000] found SMP MP-table at [mem 0x000f50d0-0x000f50df] mapped at [ffff8800000f50d0]
[ 0.000000] Base memory trampoline at [ffff880000097000] 97000 size 24576
[ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[ 0.000000] [mem 0x00000000-0x000fffff] page 4k
[ 0.000000] BRK [0x02004000, 0x02004fff] PGTABLE
[ 0.000000] BRK [0x02005000, 0x02005fff] PGTABLE
[ 0.000000] BRK [0x02006000, 0x02006fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x19fe00000-0x19fffffff]
[ 0.000000] [mem 0x19fe00000-0x19fffffff] page 2M
[ 0.000000] BRK [0x02007000, 0x02007fff] PGTABLE
[ 0.000000] init_memory_mapping: [mem 0x19c000000-0x19fdfffff]
[ 0.000000] [mem 0x19c000000-0x19fdfffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x180000000-0x19bffffff]
[ 0.000000] [mem 0x180000000-0x19bffffff] page 2M
[ 0.000000] init_memory_mapping: [mem 0x00100000-0xdfedffff]
[ 0.000000] [mem 0x00100000-0x001fffff] page 4k
[ 0.000000] [mem 0x00200000-0xdfdfffff] page 2M
[ 0.000000] [mem 0xdfe00000-0xdfedffff] page 4k
[ 0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[ 0.000000] [mem 0x100000000-0x17fffffff] page 2M
[ 0.000000] BRK [0x02008000, 0x02008fff] PGTABLE
[ 0.000000] BRK [0x02009000, 0x02009fff] PGTABLE
[ 0.000000] RAMDISK: [mem 0x35d1e000-0x36e86fff]
[ 0.000000] ACPI: Early table checksum verification disabled
[ 0.000000] ACPI: RSDP 0x00000000000F6A90 000014 (v00 GBT )
[ 0.000000] ACPI: RSDT 0x00000000DFEE3040 000038 (v01 GBT GBTUACPI 42302E31 GBTU 01010101)
[ 0.000000] ACPI: FACP 0x00000000DFEE30C0 000074 (v01 GBT GBTUACPI 42302E31 GBTU 01010101)
[ 0.000000] ACPI: DSDT 0x00000000DFEE3180 004C6F (v01 GBT GBTUACPI 00001000 MSFT 0100000C)
[ 0.000000] ACPI: FACS 0x00000000DFEE0000 000040
[ 0.000000] ACPI: HPET 0x00000000DFEE7F40 000038 (v01 GBT GBTUACPI 42302E31 GBTU 00000098)
[ 0.000000] ACPI: MCFG 0x00000000DFEE7FC0 00003C (v01 GBT GBTUACPI 42302E31 GBTU 01010101)
[ 0.000000] ACPI: APIC 0x00000000DFEE7E40 000084 (v01 GBT GBTUACPI 42302E31 GBTU 01010101)
[ 0.000000] ACPI: SSDT 0x00000000DFEE8920 0003AB (v01 PmRef CpuPm 00003000 INTL 20040311)
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] No NUMA configuration found
[ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000019fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x00000000-0x19fffffff]
[ 0.000000] NODE_DATA [mem 0x19ffe8000-0x19fffbfff]
[ 0.000000] [ffffea0000000000-ffffea00067fffff] PMD -> [ffff880199600000-ffff88019f5fffff] on node 0
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x00001000-0x00ffffff]
[ 0.000000] DMA32 [mem 0x01000000-0xffffffff]
[ 0.000000] Normal [mem 0x100000000-0x19fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x00001000-0x0009cfff]
[ 0.000000] node 0: [mem 0x00100000-0xdfedffff]
[ 0.000000] node 0: [mem 0x100000000-0x19fffffff]
[ 0.000000] On node 0 totalpages: 1572476
[ 0.000000] DMA zone: 64 pages used for memmap
[ 0.000000] DMA zone: 21 pages reserved
[ 0.000000] DMA zone: 3996 pages, LIFO batch:0
[ 0.000000] DMA32 zone: 14268 pages used for memmap
[ 0.000000] DMA32 zone: 913120 pages, LIFO batch:31
[ 0.000000] Normal zone: 10240 pages used for memmap
[ 0.000000] Normal zone: 655360 pages, LIFO batch:31
[ 0.000000] ACPI: PM-Timer IO Port: 0x408
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x03] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[ 0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[ 0.000000] nr_irqs_gsi: 40
[ 0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x0009ffff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000effff]
[ 0.000000] PM: Registered nosave memory: [mem 0x000f0000-0x000fffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xdfee0000-0xdfee2fff]
[ 0.000000] PM: Registered nosave memory: [mem 0xdfee3000-0xdfeeffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xdfef0000-0xdfefffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xdff00000-0xefffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xf0000000-0xf3ffffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xf4000000-0xfebfffff]
[ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xffffffff]
[ 0.000000] e820: [mem 0xdff00000-0xefffffff] available for PCI devices
[ 0.000000] Booting paravirtualized kernel on bare hardware
[ 0.000000] setup_percpu: NR_CPUS:1024 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 29 pages/cpu @ffff88019fc00000 s86784 r8192 d23808 u524288
[ 0.000000] pcpu-alloc: s86784 r8192 d23808 u524288 alloc=1*2097152
[ 0.000000] pcpu-alloc: [0] 0 1 2 3
[ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 1547883
[ 0.000000] Policy zone: Normal
[ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.16.2-200.fc20.x86_64 root=UUID=717c0a1b-815c-4e6a-86c0-60b921e84d75 ro rootflags=subvol=root vconsole.font=latarcyrheb-sun16 rhgb quiet LANG=en_GB.UTF-8
[ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[ 0.000000] Memory: 6090404K/6289904K available (7244K kernel code, 1127K rwdata, 3136K rodata, 1452K init, 1496K bss, 199500K reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=1024 to nr_cpu_ids=4.
[ 0.000000] Offload RCU callbacks from all CPUs
[ 0.000000] Offload RCU callbacks from CPUs: 0-3.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS:65792 nr_irqs:712 16
[ 0.000000] Console: colour VGA+ 80x25
[ 0.000000] console [tty0] enabled
[ 0.000000] allocated 25165824 bytes of page_cgroup
[ 0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[ 0.000000] hpet clockevent registered
[ 0.000000] tsc: Fast TSC calibration using PIT
[ 0.000000] tsc: Detected 2399.815 MHz processor
[ 0.001014] Calibrating delay loop (skipped), value calculated using timer frequency.. 4799.63 BogoMIPS (lpj=2399815)
[ 0.001017] pid_max: default: 32768 minimum: 301
[ 0.001029] ACPI: Core revision 20140424
[ 0.005228] ACPI: All ACPI Tables successfully acquired
[ 0.006061] Security Framework initialized
[ 0.006070] SELinux: Initializing.
[ 0.006077] SELinux: Starting in permissive mode
[ 0.007405] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
[ 0.010878] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[ 0.013266] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.013282] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
[ 0.013734] Initializing cgroup subsys memory
[ 0.013767] Initializing cgroup subsys devices
[ 0.013775] Initializing cgroup subsys freezer
[ 0.013779] Initializing cgroup subsys net_cls
[ 0.013786] Initializing cgroup subsys blkio
[ 0.013792] Initializing cgroup subsys perf_event
[ 0.013794] Initializing cgroup subsys net_prio
[ 0.013804] Initializing cgroup subsys hugetlb
[ 0.013832] CPU: Physical Processor ID: 0
[ 0.013834] CPU: Processor Core ID: 0
[ 0.013836] mce: CPU supports 6 MCE banks
[ 0.013843] CPU0: Thermal monitoring enabled (TM2)
[ 0.013852] Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32, 1GB 0
tlb_flushall_shift: -1
[ 0.013942] Freeing SMP alternatives memory: 24K (ffffffff81e86000 - ffffffff81e8c000)
[ 0.015378] ftrace: allocating 26711 entries in 105 pages
[ 0.022460] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.032852] smpboot: CPU0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (fam: 06, model: 0f, stepping: 0b)
[ 0.033000] Performance Events: PEBS fmt0+, 4-deep LBR, Core2 events, Intel PMU driver.
[ 0.033000] perf_event_intel: PEBS disabled due to CPU errata
[ 0.033000] ... version: 2
[ 0.033000] ... bit width: 40
[ 0.033000] ... generic registers: 2
[ 0.033000] ... value mask: 000000ffffffffff
[ 0.033000] ... max period: 000000007fffffff
[ 0.033000] ... fixed-purpose events: 3
[ 0.033000] ... event mask: 0000000700000003
[ 0.034011] x86: Booting SMP configuration:
[ 0.034014] .... node #0, CPUs: #1
[ 0.046096] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[ 0.046209] #2 #3
[ 0.070013] x86: Booted up 1 node, 4 CPUs
[ 0.070018] smpboot: Total of 4 processors activated (19198.52 BogoMIPS)
[ 0.072006] devtmpfs: initialized
[ 0.077238] PM: Registering ACPI NVS region [mem 0xdfee0000-0xdfee2fff] (12288 bytes)
[ 0.078548] atomic64_test: passed for x86-64 platform with CX8 and with SSE
[ 0.078552] pinctrl core: initialized pinctrl subsystem
[ 0.078593] RTC time: 12:03:45, date: 09/19/14
[ 0.078651] NET: Registered protocol family 16
[ 0.078793] cpuidle: using governor menu
[ 0.078861] ACPI: bus type PCI registered
[ 0.078863] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.078947] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf0000000-0xf3ffffff] (base 0xf0000000)
[ 0.078949] PCI: MMCONFIG at [mem 0xf0000000-0xf3ffffff] reserved in E820
[ 0.079053] PCI: Using configuration type 1 for base access
[ 0.082113] ACPI: Added _OSI(Module Device)
[ 0.082113] ACPI: Added _OSI(Processor Device)
[ 0.082113] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.082113] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.087059] ACPI: Dynamic OEM Table Load:
[ 0.087068] ACPI: SSDT 0xFFFF880196484800 00022A (v01 PmRef Cpu0Ist 00003000 INTL 20040311)
[ 0.087334] ACPI: Dynamic OEM Table Load:
[ 0.087339] ACPI: SSDT 0xFFFF880196461200 000152 (v01 PmRef Cpu1Ist 00003000 INTL 20040311)
[ 0.087591] ACPI: Dynamic OEM Table Load:
[ 0.087596] ACPI: SSDT 0xFFFF880196461400 000152 (v01 PmRef Cpu2Ist 00003000 INTL 20040311)
[ 0.087848] ACPI: Dynamic OEM Table Load:
[ 0.087853] ACPI: SSDT 0xFFFF880196461600 000152 (v01 PmRef Cpu3Ist 00003000 INTL 20040311)
[ 0.088142] ACPI: Interpreter enabled
[ 0.088148] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140424/hwxface-580)
[ 0.088152] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140424/hwxface-580)
[ 0.088166] ACPI: (supports S0 S3 S4 S5)
[ 0.088168] ACPI: Using IOAPIC for interrupt routing
[ 0.088197] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 0.092861] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f])
[ 0.092868] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[ 0.092873] acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
[ 0.093107] PCI host bridge to bus 0000:00
[ 0.093110] pci_bus 0000:00: root bus resource [bus 00-3f]
[ 0.093113] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7]
[ 0.093115] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff]
[ 0.093117] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[ 0.093120] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff]
[ 0.093122] pci_bus 0000:00: root bus resource [mem 0xdff00000-0xfebfffff]
[ 0.093131] pci 0000:00:00.0: [8086:29c0] type 00 class 0x060000
[ 0.093236] pci 0000:00:01.0: [8086:29c1] type 01 class 0x060400
[ 0.093276] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[ 0.093381] pci 0000:00:1a.0: [8086:2937] type 00 class 0x0c0300
[ 0.093421] pci 0000:00:1a.0: reg 0x20: [io 0xe000-0xe01f]
[ 0.093494] pci 0000:00:1a.0: System wakeup disabled by ACPI
[ 0.093544] pci 0000:00:1a.1: [8086:2938] type 00 class 0x0c0300
[ 0.093583] pci 0000:00:1a.1: reg 0x20: [io 0xe100-0xe11f]
[ 0.093657] pci 0000:00:1a.1: System wakeup disabled by ACPI
[ 0.093706] pci 0000:00:1a.2: [8086:2939] type 00 class 0x0c0300
[ 0.093745] pci 0000:00:1a.2: reg 0x20: [io 0xe500-0xe51f]
[ 0.093818] pci 0000:00:1a.2: System wakeup disabled by ACPI
[ 0.093881] pci 0000:00:1a.7: [8086:293c] type 00 class 0x0c0320
[ 0.093897] pci 0000:00:1a.7: reg 0x10: [mem 0xf9004000-0xf90043ff]
[ 0.094000] pci 0000:00:1a.7: System wakeup disabled by ACPI
[ 0.094050] pci 0000:00:1b.0: [8086:293e] type 00 class 0x040300
[ 0.094065] pci 0000:00:1b.0: reg 0x10: [mem 0xf9000000-0xf9003fff 64bit]
[ 0.094133] pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
[ 0.094177] pci 0000:00:1b.0: System wakeup disabled by ACPI
[ 0.094227] pci 0000:00:1c.0: [8086:2940] type 01 class 0x060400
[ 0.094295] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[ 0.094343] pci 0000:00:1c.0: System wakeup disabled by ACPI
[ 0.094397] pci 0000:00:1c.4: [8086:2948] type 01 class 0x060400
[ 0.094466] pci 0000:00:1c.4: PME# supported from D0 D3hot D3cold
[ 0.094511] pci 0000:00:1c.4: System wakeup disabled by ACPI
[ 0.094560] pci 0000:00:1c.5: [8086:294a] type 01 class 0x060400
[ 0.094628] pci 0000:00:1c.5: PME# supported from D0 D3hot D3cold
[ 0.094677] pci 0000:00:1c.5: System wakeup disabled by ACPI
[ 0.094728] pci 0000:00:1d.0: [8086:2934] type 00 class 0x0c0300
[ 0.094767] pci 0000:00:1d.0: reg 0x20: [io 0xe200-0xe21f]
[ 0.094839] pci 0000:00:1d.0: System wakeup disabled by ACPI
[ 0.094899] pci 0000:00:1d.1: [8086:2935] type 00 class 0x0c0300
[ 0.094938] pci 0000:00:1d.1: reg 0x20: [io 0xe300-0xe31f]
[ 0.095003] pci 0000:00:1d.1: System wakeup disabled by ACPI
[ 0.095052] pci 0000:00:1d.2: [8086:2936] type 00 class 0x0c0300
[ 0.095091] pci 0000:00:1d.2: reg 0x20: [io 0xe400-0xe41f]
[ 0.095163] pci 0000:00:1d.2: System wakeup disabled by ACPI
[ 0.095218] pci 0000:00:1d.7: [8086:293a] type 00 class 0x0c0320
[ 0.095234] pci 0000:00:1d.7: reg 0x10: [mem 0xf9005000-0xf90053ff]
[ 0.095339] pci 0000:00:1d.7: System wakeup disabled by ACPI
[ 0.095390] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401
[ 0.095470] pci 0000:00:1e.0: System wakeup disabled by ACPI
[ 0.095520] pci 0000:00:1f.0: [8086:2918] type 00 class 0x060100
[ 0.095593] pci 0000:00:1f.0: can't claim BAR 13 [io 0x0400-0x047f]: address conflict with ACPI CPU throttle [io 0x0410-0x0415]
[ 0.095598] pci 0000:00:1f.0: quirk: [io 0x0480-0x04bf] claimed by ICH6 GPIO
[ 0.095602] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 000f)
[ 0.095605] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 000f)
[ 0.095722] pci 0000:00:1f.2: [8086:2923] type 00 class 0x010601
[ 0.095739] pci 0000:00:1f.2: reg 0x10: [io 0xe600-0xe607]
[ 0.095747] pci 0000:00:1f.2: reg 0x14: [io 0xe700-0xe703]
[ 0.095754] pci 0000:00:1f.2: reg 0x18: [io 0xe800-0xe807]
[ 0.095761] pci 0000:00:1f.2: reg 0x1c: [io 0xe900-0xe903]
[ 0.095769] pci 0000:00:1f.2: reg 0x20: [io 0xea00-0xea1f]
[ 0.095777] pci 0000:00:1f.2: reg 0x24: [mem 0xf9006000-0xf90067ff]
[ 0.095819] pci 0000:00:1f.2: PME# supported from D3hot
[ 0.095912] pci 0000:00:1f.3: [8086:2930] type 00 class 0x0c0500
[ 0.095926] pci 0000:00:1f.3: reg 0x10: [mem 0xf9007000-0xf90070ff 64bit]
[ 0.095946] pci 0000:00:1f.3: reg 0x20: [io 0x0500-0x051f]
[ 0.096076] pci 0000:01:00.0: [1002:68f9] type 00 class 0x030000
[ 0.096091] pci 0000:01:00.0: reg 0x10: [mem 0xe0000000-0xefffffff 64bit pref]
[ 0.096101] pci 0000:01:00.0: reg 0x18: [mem 0xf5000000-0xf501ffff 64bit]
[ 0.096108] pci 0000:01:00.0: reg 0x20: [io 0xa000-0xa0ff]
[ 0.096121] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0001ffff pref]
[ 0.096153] pci 0000:01:00.0: supports D1 D2
[ 0.096205] pci 0000:01:00.1: [1002:aa68] type 00 class 0x040300
[ 0.096219] pci 0000:01:00.1: reg 0x10: [mem 0xf5020000-0xf5023fff 64bit]
[ 0.096275] pci 0000:01:00.1: supports D1 D2
[ 0.096337] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 0.096340] pci 0000:00:01.0: bridge window [io 0xa000-0xafff]
[ 0.096343] pci 0000:00:01.0: bridge window [mem 0xf4000000-0xf5ffffff]
[ 0.096347] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref]
[ 0.096403] pci 0000:00:1c.0: PCI bridge to [bus 02]
[ 0.096407] pci 0000:00:1c.0: bridge window [io 0x9000-0x9fff]
[ 0.096497] pci 0000:03:00.0: [197b:2368] type 00 class 0x010185
[ 0.096529] pci 0000:03:00.0: reg 0x10: [io 0xb000-0xb007]
[ 0.096542] pci 0000:03:00.0: reg 0x14: [io 0xb100-0xb103]
[ 0.096556] pci 0000:03:00.0: reg 0x18: [io 0xb200-0xb207]
[ 0.096569] pci 0000:03:00.0: reg 0x1c: [io 0xb300-0xb303]
[ 0.096583] pci 0000:03:00.0: reg 0x20: [io 0xb400-0xb40f]
[ 0.096724] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 0.096734] pci 0000:00:1c.4: PCI bridge to [bus 03]
[ 0.096738] pci 0000:00:1c.4: bridge window [io 0xb000-0xbfff]
[ 0.096741] pci 0000:00:1c.4: bridge window [mem 0xf6000000-0xf6ffffff]
[ 0.096823] pci 0000:04:00.0: [10ec:8168] type 00 class 0x020000
[ 0.096843] pci 0000:04:00.0: reg 0x10: [io 0xc000-0xc0ff]
[ 0.096874] pci 0000:04:00.0: reg 0x18: [mem 0xf8000000-0xf8000fff 64bit]
[ 0.096918] pci 0000:04:00.0: reg 0x30: [mem 0x00000000-0x0001ffff pref]
[ 0.097005] pci 0000:04:00.0: supports D1 D2
[ 0.097008] pci 0000:04:00.0: PME# supported from D1 D2 D3hot D3cold
[ 0.097072] pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 0.097081] pci 0000:00:1c.5: PCI bridge to [bus 04]
[ 0.097085] pci 0000:00:1c.5: bridge window [io 0xc000-0xcfff]
[ 0.097089] pci 0000:00:1c.5: bridge window [mem 0xf7000000-0xf8ffffff]
[ 0.097141] pci 0000:05:01.0: [1102:0002] type 00 class 0x040100
[ 0.097157] pci 0000:05:01.0: reg 0x10: [io 0xd000-0xd01f]
[ 0.097227] pci 0000:05:01.0: supports D1 D2
[ 0.097275] pci 0000:05:01.1: [1102:7002] type 00 class 0x098000
[ 0.097291] pci 0000:05:01.1: reg 0x10: [io 0xd100-0xd107]
[ 0.097360] pci 0000:05:01.1: supports D1 D2
[ 0.097441] pci 0000:00:1e.0: PCI bridge to [bus 05] (subtractive decode)
[ 0.097445] pci 0000:00:1e.0: bridge window [io 0xd000-0xdfff]
[ 0.097452] pci 0000:00:1e.0: bridge window [io 0x0000-0x0cf7] (subtractive decode)
[ 0.097454] pci 0000:00:1e.0: bridge window [io 0x0d00-0xffff] (subtractive decode)
[ 0.097456] pci 0000:00:1e.0: bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[ 0.097459] pci 0000:00:1e.0: bridge window [mem 0x000c0000-0x000dffff] (subtractive decode)
[ 0.097461] pci 0000:00:1e.0: bridge window [mem 0xdff00000-0xfebfffff] (subtractive decode)
[ 0.098026] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14 *15)
[ 0.098081] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
[ 0.098135] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
[ 0.098187] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
[ 0.098240] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11 12 14 15) *0, disabled.
[ 0.098294] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12 14 *15)
[ 0.098347] ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 9 10 11 12 *14 15)
[ 0.098400] ACPI: PCI Interrupt Link [LNK1] (IRQs *3 4 5 6 7 9 10 11 12 14 15)
[ 0.098604] vgaarb: device added: PCI:0000:01:00.0,decodes=io+mem,owns=io+mem,locks=none
[ 0.098604] vgaarb: loaded
[ 0.098604] vgaarb: bridge control possible 0000:01:00.0
[ 0.098604] SCSI subsystem initialized
[ 0.098604] libata version 3.00 loaded.
[ 0.098604] ACPI: bus type USB registered
[ 0.098604] usbcore: registered new interface driver usbfs
[ 0.098604] usbcore: registered new interface driver hub
[ 0.098604] usbcore: registered new device driver usb
[ 0.099040] PCI: Using ACPI for IRQ routing
[ 0.100370] PCI: pci_cache_line_size set to 64 bytes
[ 0.100426] e820: reserve RAM buffer [mem 0x0009dc00-0x0009ffff]
[ 0.100428] e820: reserve RAM buffer [mem 0xdfee0000-0xdfffffff]
[ 0.100560] NetLabel: Initializing
[ 0.100562] NetLabel: domain hash size = 128
[ 0.100563] NetLabel: protocols = UNLABELED CIPSOv4
[ 0.100580] NetLabel: unlabeled traffic allowed by default
[ 0.100632] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[ 0.100637] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[ 0.100641] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[ 0.102043] Switched to clocksource hpet
[ 0.111214] pnp: PnP ACPI init
[ 0.111235] ACPI: bus type PNP registered
[ 0.111436] system 00:00: [io 0x04d0-0x04d1] has been reserved
[ 0.111439] system 00:00: [io 0x0290-0x029f] has been reserved
[ 0.111444] system 00:00: [io 0x0800-0x087f] has been reserved
[ 0.111447] system 00:00: [io 0x0290-0x0294] has been reserved
[ 0.111449] system 00:00: [io 0x0880-0x088f] has been reserved
[ 0.111453] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.111529] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active)
[ 0.111644] pnp 00:02: [dma 2]
[ 0.111687] pnp 00:02: Plug and Play ACPI device, IDs PNP0700 (active)
[ 0.111886] pnp 00:03: Plug and Play ACPI device, IDs PNP0501 (active)
[ 0.112093] pnp 00:04: Plug and Play ACPI device, IDs PNP0400 (active)
[ 0.112236] system 00:05: [io 0x0400-0x04bf] could not be reserved
[ 0.112240] system 00:05: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.112448] system 00:06: [mem 0xf0000000-0xf3ffffff] has been reserved
[ 0.112452] system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
[ 0.112649] system 00:07: [mem 0x000d3800-0x000d3fff] has been reserved
[ 0.112652] system 00:07: [mem 0x000f0000-0x000f7fff] could not be reserved
[ 0.112654] system 00:07: [mem 0x000f8000-0x000fbfff] could not be reserved
[ 0.112657] system 00:07: [mem 0x000fc000-0x000fffff] could not be reserved
[ 0.112659] system 00:07: [mem 0xdfee0000-0xdfefffff] could not be reserved
[ 0.112662] system 00:07: [mem 0x00000000-0x0009ffff] could not be reserved
[ 0.112664] system 00:07: [mem 0x00100000-0xdfedffff] could not be reserved
[ 0.112667] system 00:07: [mem 0xfec00000-0xfec00fff] could not be reserved
[ 0.112669] system 00:07: [mem 0xfed10000-0xfed1dfff] has been reserved
[ 0.112671] system 00:07: [mem 0xfed20000-0xfed8ffff] has been reserved
[ 0.112674] system 00:07: [mem 0xfee00000-0xfee00fff] has been reserved
[ 0.112676] system 00:07: [mem 0xffb00000-0xffb7ffff] has been reserved
[ 0.112678] system 00:07: [mem 0xfff00000-0xffffffff] has been reserved
[ 0.112681] system 00:07: [mem 0x000e0000-0x000effff] has been reserved
[ 0.112684] system 00:07: Plug and Play ACPI device, IDs PNP0c01 (active)
[ 0.112690] pnp: PnP ACPI: found 8 devices
[ 0.112692] ACPI: bus type PNP unregistered
[ 0.121373] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 02] add_size 200000
[ 0.121376] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff] to [bus 02] add_size 200000
[ 0.121385] pci 0000:00:1c.4: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 03] add_size 200000
[ 0.121392] pci 0000:00:1c.5: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 04] add_size 200000
[ 0.121403] pci 0000:00:1f.0: BAR 13: [io 0x0400-0x047f] has bogus alignment
[ 0.121407] pci 0000:00:1c.0: res[14]=[mem 0x00100000-0x000fffff] get_res_add_size add_size 200000
[ 0.121409] pci 0000:00:1c.0: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 0.121412] pci 0000:00:1c.4: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 0.121414] pci 0000:00:1c.5: res[15]=[mem 0x00100000-0x000fffff 64bit pref] get_res_add_size add_size 200000
[ 0.121420] pci 0000:00:1c.0: BAR 14: assigned [mem 0xf9100000-0xf92fffff]
[ 0.121426] pci 0000:00:1c.0: BAR 15: assigned [mem 0xf9300000-0xf94fffff 64bit pref]
[ 0.121430] pci 0000:00:1c.4: BAR 15: assigned [mem 0xf9500000-0xf96fffff 64bit pref]
[ 0.121435] pci 0000:00:1c.5: BAR 15: assigned [mem 0xf9700000-0xf98fffff 64bit pref]
[ 0.121439] pci 0000:01:00.0: BAR 6: assigned [mem 0xf4000000-0xf401ffff pref]
[ 0.121442] pci 0000:00:01.0: PCI bridge to [bus 01]
[ 0.121445] pci 0000:00:01.0: bridge window [io 0xa000-0xafff]
[ 0.121449] pci 0000:00:01.0: bridge window [mem 0xf4000000-0xf5ffffff]
[ 0.121452] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xefffffff 64bit pref]
[ 0.121456] pci 0000:00:1c.0: PCI bridge to [bus 02]
[ 0.121458] pci 0000:00:1c.0: bridge window [io 0x9000-0x9fff]
[ 0.121463] pci 0000:00:1c.0: bridge window [mem 0xf9100000-0xf92fffff]
[ 0.121466] pci 0000:00:1c.0: bridge window [mem 0xf9300000-0xf94fffff 64bit pref]
[ 0.121472] pci 0000:00:1c.4: PCI bridge to [bus 03]
[ 0.121474] pci 0000:00:1c.4: bridge window [io 0xb000-0xbfff]
[ 0.121479] pci 0000:00:1c.4: bridge window [mem 0xf6000000-0xf6ffffff]
[ 0.121483] pci 0000:00:1c.4: bridge window [mem 0xf9500000-0xf96fffff 64bit pref]
[ 0.121489] pci 0000:04:00.0: BAR 6: assigned [mem 0xf7000000-0xf701ffff pref]
[ 0.121491] pci 0000:00:1c.5: PCI bridge to [bus 04]
[ 0.121494] pci 0000:00:1c.5: bridge window [io 0xc000-0xcfff]
[ 0.121498] pci 0000:00:1c.5: bridge window [mem 0xf7000000-0xf8ffffff]
[ 0.121502] pci 0000:00:1c.5: bridge window [mem 0xf9700000-0xf98fffff 64bit pref]
[ 0.121507] pci 0000:00:1e.0: PCI bridge to [bus 05]
[ 0.121510] pci 0000:00:1e.0: bridge window [io 0xd000-0xdfff]
[ 0.121520] pci_bus 0000:00: resource 4 [io 0x0000-0x0cf7]
[ 0.121522] pci_bus 0000:00: resource 5 [io 0x0d00-0xffff]
[ 0.121524] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[ 0.121526] pci_bus 0000:00: resource 7 [mem 0x000c0000-0x000dffff]
[ 0.121528] pci_bus 0000:00: resource 8 [mem 0xdff00000-0xfebfffff]
[ 0.121530] pci_bus 0000:01: resource 0 [io 0xa000-0xafff]
[ 0.121533] pci_bus 0000:01: resource 1 [mem 0xf4000000-0xf5ffffff]
[ 0.121535] pci_bus 0000:01: resource 2 [mem 0xe0000000-0xefffffff 64bit pref]
[ 0.121537] pci_bus 0000:02: resource 0 [io 0x9000-0x9fff]
[ 0.121539] pci_bus 0000:02: resource 1 [mem 0xf9100000-0xf92fffff]
[ 0.121541] pci_bus 0000:02: resource 2 [mem 0xf9300000-0xf94fffff 64bit pref]
[ 0.121543] pci_bus 0000:03: resource 0 [io 0xb000-0xbfff]
[ 0.121545] pci_bus 0000:03: resource 1 [mem 0xf6000000-0xf6ffffff]
[ 0.121548] pci_bus 0000:03: resource 2 [mem 0xf9500000-0xf96fffff 64bit pref]
[ 0.121550] pci_bus 0000:04: resource 0 [io 0xc000-0xcfff]
[ 0.121552] pci_bus 0000:04: resource 1 [mem 0xf7000000-0xf8ffffff]
[ 0.121554] pci_bus 0000:04: resource 2 [mem 0xf9700000-0xf98fffff 64bit pref]
[ 0.121556] pci_bus 0000:05: resource 0 [io 0xd000-0xdfff]
[ 0.121558] pci_bus 0000:05: resource 4 [io 0x0000-0x0cf7]
[ 0.121560] pci_bus 0000:05: resource 5 [io 0x0d00-0xffff]
[ 0.121562] pci_bus 0000:05: resource 6 [mem 0x000a0000-0x000bffff]
[ 0.121564] pci_bus 0000:05: resource 7 [mem 0x000c0000-0x000dffff]
[ 0.121566] pci_bus 0000:05: resource 8 [mem 0xdff00000-0xfebfffff]
[ 0.121602] NET: Registered protocol family 2
[ 0.121851] TCP established hash table entries: 65536 (order: 7, 524288 bytes)
[ 0.122188] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[ 0.122621] TCP: Hash tables configured (established 65536 bind 65536)
[ 0.122672] TCP: reno registered
[ 0.122687] UDP hash table entries: 4096 (order: 5, 131072 bytes)
[ 0.122752] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
[ 0.122886] NET: Registered protocol family 1
[ 0.123847] pci 0000:01:00.0: Boot video device
[ 0.123861] PCI: CLS 32 bytes, default 64
[ 0.123939] Unpacking initramfs...
[ 0.449438] Freeing initrd memory: 17828K (ffff880035d1e000 - ffff880036e87000)
[ 0.449457] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.449460] software IO TLB [mem 0xdbee0000-0xdfee0000] (64MB) mapped at [ffff8800dbee0000-ffff8800dfedffff]
[ 0.450629] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.450654] Initialise system trusted keyring
[ 0.450683] audit: initializing netlink subsys (disabled)
[ 0.450710] audit: type=2000 audit(1411128225.449:1): initialized
[ 0.451091] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[ 0.453213] zbud: loaded
[ 0.453446] VFS: Disk quotas dquot_6.5.2
[ 0.453515] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[ 0.454031] msgmni has been set to 11930
[ 0.454101] Key type big_key registered
[ 0.454104] SELinux: Registering netfilter hooks
[ 0.455427] alg: No test for stdrng (krng)
[ 0.455446] NET: Registered protocol family 38
[ 0.455456] Key type asymmetric registered
[ 0.455459] Asymmetric key parser 'x509' registered
[ 0.455508] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[ 0.455590] io scheduler noop registered
[ 0.455593] io scheduler deadline registered
[ 0.455655] io scheduler cfq registered (default)
[ 0.455882] pcieport 0000:00:01.0: irq 40 for MSI/MSI-X
[ 0.455997] pcieport 0000:00:1c.0: irq 41 for MSI/MSI-X
[ 0.456134] pcieport 0000:00:1c.4: irq 42 for MSI/MSI-X
[ 0.456259] pcieport 0000:00:1c.5: irq 43 for MSI/MSI-X
[ 0.456356] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.456376] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 0.456435] intel_idle: does not run on family 6 model 15
[ 0.456526] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[ 0.456530] ACPI: Power Button [PWRB]
[ 0.456590] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 0.456592] ACPI: Power Button [PWRF]
[ 0.457058] GHES: HEST is not enabled!
[ 0.457184] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.477708] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 0.478262] Non-volatile memory driver v1.3
[ 0.478266] Linux agpgart interface v0.103
[ 0.478506] ahci 0000:00:1f.2: version 3.0
[ 0.478598] ahci 0000:00:1f.2: irq 44 for MSI/MSI-X
[ 0.478633] ahci 0000:00:1f.2: SSS flag set, parallel bus scan disabled
[ 0.478659] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 4 ports 3 Gbps 0x33 impl SATA mode
[ 0.478663] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp pio slum part ccc ems
[ 0.484845] scsi0 : ahci
[ 0.485037] scsi1 : ahci
[ 0.485181] scsi2 : ahci
[ 0.485321] scsi3 : ahci
[ 0.485463] scsi4 : ahci
[ 0.485601] scsi5 : ahci
[ 0.485656] ata1: SATA max UDMA/133 abar m2048@0xf9006000 port 0xf9006100 irq 44
[ 0.485659] ata2: SATA max UDMA/133 abar m2048@0xf9006000 port 0xf9006180 irq 44
[ 0.485660] ata3: DUMMY
[ 0.485661] ata4: DUMMY
[ 0.485663] ata5: SATA max UDMA/133 abar m2048@0xf9006000 port 0xf9006300 irq 44
[ 0.485666] ata6: SATA max UDMA/133 abar m2048@0xf9006000 port 0xf9006380 irq 44
[ 0.485775] libphy: Fixed MDIO Bus: probed
[ 0.485852] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.485857] ehci-pci: EHCI PCI platform driver
[ 0.485950] ehci-pci 0000:00:1a.7: EHCI Host Controller
[ 0.486018] ehci-pci 0000:00:1a.7: new USB bus registered, assigned bus number 1
[ 0.489928] ehci-pci 0000:00:1a.7: cache line size of 32 is not supported
[ 0.489943] ehci-pci 0000:00:1a.7: irq 18, io mem 0xf9004000
[ 0.495076] ehci-pci 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[ 0.495151] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.495155] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.495158] usb usb1: Product: EHCI Host Controller
[ 0.495161] usb usb1: Manufacturer: Linux 3.16.2-200.fc20.x86_64 ehci_hcd
[ 0.495164] usb usb1: SerialNumber: 0000:00:1a.7
[ 0.495321] hub 1-0:1.0: USB hub found
[ 0.495328] hub 1-0:1.0: 6 ports detected
[ 0.495579] ehci-pci 0000:00:1d.7: EHCI Host Controller
[ 0.495625] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 2
[ 0.499542] ehci-pci 0000:00:1d.7: cache line size of 32 is not supported
[ 0.499558] ehci-pci 0000:00:1d.7: irq 23, io mem 0xf9005000
[ 0.505068] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[ 0.505123] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[ 0.505127] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.505130] usb usb2: Product: EHCI Host Controller
[ 0.505133] usb usb2: Manufacturer: Linux 3.16.2-200.fc20.x86_64 ehci_hcd
[ 0.505137] usb usb2: SerialNumber: 0000:00:1d.7
[ 0.505286] hub 2-0:1.0: USB hub found
[ 0.505293] hub 2-0:1.0: 6 ports detected
[ 0.505470] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.505475] ohci-pci: OHCI PCI platform driver
[ 0.505492] uhci_hcd: USB Universal Host Controller Interface driver
[ 0.505576] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[ 0.505626] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[ 0.505632] uhci_hcd 0000:00:1a.0: detected 2 ports
[ 0.505660] uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e000
[ 0.505707] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.505710] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.505712] usb usb3: Product: UHCI Host Controller
[ 0.505714] usb usb3: Manufacturer: Linux 3.16.2-200.fc20.x86_64 uhci_hcd
[ 0.505716] usb usb3: SerialNumber: 0000:00:1a.0
[ 0.505831] hub 3-0:1.0: USB hub found
[ 0.505838] hub 3-0:1.0: 2 ports detected
[ 0.506010] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[ 0.506056] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[ 0.506062] uhci_hcd 0000:00:1a.1: detected 2 ports
[ 0.506087] uhci_hcd 0000:00:1a.1: irq 21, io base 0x0000e100
[ 0.506136] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.506138] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.506140] usb usb4: Product: UHCI Host Controller
[ 0.506142] usb usb4: Manufacturer: Linux 3.16.2-200.fc20.x86_64 uhci_hcd
[ 0.506145] usb usb4: SerialNumber: 0000:00:1a.1
[ 0.506258] hub 4-0:1.0: USB hub found
[ 0.506265] hub 4-0:1.0: 2 ports detected
[ 0.506432] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[ 0.506479] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[ 0.506485] uhci_hcd 0000:00:1a.2: detected 2 ports
[ 0.506503] uhci_hcd 0000:00:1a.2: irq 18, io base 0x0000e500
[ 0.506548] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.506551] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.506553] usb usb5: Product: UHCI Host Controller
[ 0.506555] usb usb5: Manufacturer: Linux 3.16.2-200.fc20.x86_64 uhci_hcd
[ 0.506557] usb usb5: SerialNumber: 0000:00:1a.2
[ 0.506670] hub 5-0:1.0: USB hub found
[ 0.506677] hub 5-0:1.0: 2 ports detected
[ 0.506841] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[ 0.506886] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[ 0.506892] uhci_hcd 0000:00:1d.0: detected 2 ports
[ 0.506909] uhci_hcd 0000:00:1d.0: irq 23, io base 0x0000e200
[ 0.506955] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.506957] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.506959] usb usb6: Product: UHCI Host Controller
[ 0.506962] usb usb6: Manufacturer: Linux 3.16.2-200.fc20.x86_64 uhci_hcd
[ 0.506964] usb usb6: SerialNumber: 0000:00:1d.0
[ 0.507085] hub 6-0:1.0: USB hub found
[ 0.507092] hub 6-0:1.0: 2 ports detected
[ 0.507257] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[ 0.507309] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[ 0.507315] uhci_hcd 0000:00:1d.1: detected 2 ports
[ 0.507343] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000e300
[ 0.507390] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.507392] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.507394] usb usb7: Product: UHCI Host Controller
[ 0.507397] usb usb7: Manufacturer: Linux 3.16.2-200.fc20.x86_64 uhci_hcd
[ 0.507399] usb usb7: SerialNumber: 0000:00:1d.1
[ 0.507513] hub 7-0:1.0: USB hub found
[ 0.507523] hub 7-0:1.0: 2 ports detected
[ 0.507689] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[ 0.507736] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[ 0.507744] uhci_hcd 0000:00:1d.2: detected 2 ports
[ 0.507762] uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000e400
[ 0.507806] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
[ 0.507809] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.507811] usb usb8: Product: UHCI Host Controller
[ 0.507813] usb usb8: Manufacturer: Linux 3.16.2-200.fc20.x86_64 uhci_hcd
[ 0.507815] usb usb8: SerialNumber: 0000:00:1d.2
[ 0.507935] hub 8-0:1.0: USB hub found
[ 0.507942] hub 8-0:1.0: 2 ports detected
[ 0.508120] usbcore: registered new interface driver usbserial
[ 0.508130] usbcore: registered new interface driver usbserial_generic
[ 0.508140] usbserial: USB Serial support registered for generic
[ 0.508175] i8042: PNP: No PS/2 controller found. Probing ports directly.
[ 0.508560] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 0.508568] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 0.508740] mousedev: PS/2 mouse device common for all mice
[ 0.508988] rtc_cmos 00:01: RTC can wake from S4
[ 0.509163] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0
[ 0.509193] rtc_cmos 00:01: alarms up to one month, 242 bytes nvram, hpet irqs
[ 0.509320] device-mapper: uevent: version 1.0.3
[ 0.509413] device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
[ 0.509884] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.510027] usbcore: registered new interface driver usbhid
[ 0.510029] usbhid: USB HID core driver
[ 0.510066] drop_monitor: Initializing network drop monitor service
[ 0.510146] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 0.510187] TCP: cubic registered
[ 0.510209] Initializing XFRM netlink socket
[ 0.510353] NET: Registered protocol family 10
[ 0.510588] mip6: Mobile IPv6
[ 0.510591] NET: Registered protocol family 17
[ 0.510930] Loading compiled-in X.509 certificates
[ 0.512062] Loaded X.509 cert 'Fedora kernel signing key: c0aa8b1b8df81c4f973aedc90cf7faca93b33804'
[ 0.512077] registered taskstats version 1
[ 0.512522] Magic number: 14:231:77
[ 0.512638] rtc_cmos 00:01: setting system clock to 2014-09-19 12:03:45 UTC (1411128225)
[ 0.512722] PM: Hibernation image not present or could not be loaded.
[ 0.790092] ata1: SATA link down (SStatus 0 SControl 300)
[ 0.797627] usb 1-3: new high-speed USB device number 2 using ehci-pci
[ 0.911865] usb 1-3: New USB device found, idVendor=050d, idProduct=0307
[ 0.911870] usb 1-3: New USB device strings: Mfr=0, Product=1, SerialNumber=2
[ 0.911874] usb 1-3: Product: USB 2.0 Hub [MTT]
[ 0.911877] usb 1-3: SerialNumber: 001
[ 0.912174] hub 1-3:1.0: USB hub found
[ 0.912239] hub 1-3:1.0: 7 ports detected
[ 1.095091] ata2: SATA link down (SStatus 0 SControl 300)
[ 1.176619] usb 1-3.1: new high-speed USB device number 3 using ehci-pci
[ 1.250492] usb 1-3.1: New USB device found, idVendor=050d, idProduct=0307
[ 1.250496] usb 1-3.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.250807] hub 1-3.1:1.0: USB hub found
[ 1.250863] hub 1-3.1:1.0: 7 ports detected
[ 1.314740] usb 1-3.2: new low-speed USB device number 4 using ehci-pci
[ 1.396615] usb 1-3.2: New USB device found, idVendor=046d, idProduct=c31f
[ 1.396619] usb 1-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.396622] usb 1-3.2: Product: USB Keyboard
[ 1.396625] usb 1-3.2: Manufacturer: Logitech
[ 1.402003] input: Logitech USB Keyboard as /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3.2/1-3.2:1.0/0003:046D:C31F.0001/input/input5
[ 1.402132] hid-generic 0003:046D:C31F.0001: input,hidraw0: USB HID v1.10 Keyboard [Logitech USB Keyboard] on usb-0000:00:1a.7-3.2/input0
[ 1.408239] input: Logitech USB Keyboard as /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3.2/1-3.2:1.1/0003:046D:C31F.0002/input/input6
[ 1.408394] hid-generic 0003:046D:C31F.0002: input,hiddev0,hidraw1: USB HID v1.10 Device [Logitech USB Keyboard] on usb-0000:00:1a.7-3.2/input1
[ 1.452474] tsc: Refined TSC clocksource calibration: 2399.970 MHz
[ 1.470496] usb 1-3.3: new full-speed USB device number 5 using ehci-pci
[ 1.547490] usb 1-3.3: New USB device found, idVendor=046d, idProduct=c52b
[ 1.547494] usb 1-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.547497] usb 1-3.3: Product: USB Receiver
[ 1.547500] usb 1-3.3: Manufacturer: Logitech
[ 1.555057] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.556109] ata5.00: ATA-8: ST3000DM001-1CH166, CC24, max UDMA/133
[ 1.556114] ata5.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[ 1.557025] ata5.00: configured for UDMA/133
[ 1.557170] scsi 4:0:0:0: Direct-Access ATA ST3000DM001-1CH1 CC24 PQ: 0 ANSI: 5
[ 1.557414] sd 4:0:0:0: Attached scsi generic sg0 type 0
[ 1.557428] sd 4:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.72 TiB)
[ 1.557431] sd 4:0:0:0: [sda] 4096-byte physical blocks
[ 1.557512] sd 4:0:0:0: [sda] Write Protect is off
[ 1.557516] sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.557548] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.612150] sda: sda1 sda2 sda3 sda4
[ 1.612644] sd 4:0:0:0: [sda] Attached SCSI disk
[ 1.615742] usb 1-3.6: new full-speed USB device number 6 using ehci-pci
[ 1.696371] usb 1-3.6: New USB device found, idVendor=0403, idProduct=6001
[ 1.696376] usb 1-3.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1.696379] usb 1-3.6: Product: TTL232R-3V3
[ 1.696383] usb 1-3.6: Manufacturer: FTDI
[ 1.696386] usb 1-3.6: SerialNumber: FTGW5K3N
[ 1.760619] usb 1-3.7: new high-speed USB device number 7 using ehci-pci
[ 1.834491] usb 1-3.7: New USB device found, idVendor=050d, idProduct=0307
[ 1.834495] usb 1-3.7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1.834787] hub 1-3.7:1.0: USB hub found
[ 1.834863] hub 1-3.7:1.0: 7 ports detected
[ 1.862082] ata6: SATA link down (SStatus 0 SControl 300)
[ 1.863421] Freeing unused kernel memory: 1452K (ffffffff81d1b000 - ffffffff81e86000)
[ 1.863423] Write protecting the kernel read-only data: 12288k
[ 1.866177] Freeing unused kernel memory: 936K (ffff880001716000 - ffff880001800000)
[ 1.868727] Freeing unused kernel memory: 960K (ffff880001b10000 - ffff880001c00000)
[ 1.871882] systemd[1]: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
[ 1.872081] systemd[1]: Running in initial RAM disk.
[ 1.872138] systemd[1]: Set hostname to <zarniwoop.blob>.
[ 1.872692] random: systemd urandom read with 31 bits of entropy available
[ 1.904245] systemd[1]: Expecting device dev-disk-by\x2duuid-717c0a1b\x2d815c\x2d4e6a\x2d86c0\x2d60b921e84d75.device...
[ 1.904261] systemd[1]: Starting -.slice.
[ 1.904562] systemd[1]: Created slice -.slice.
[ 1.904573] systemd[1]: Starting System Slice.
[ 1.904645] systemd[1]: Created slice System Slice.
[ 1.904656] systemd[1]: Starting Slices.
[ 1.904667] systemd[1]: Reached target Slices.
[ 1.904676] systemd[1]: Starting Timers.
[ 1.904688] systemd[1]: Reached target Timers.
[ 1.904699] systemd[1]: Starting Journal Socket.
[ 1.904757] systemd[1]: Listening on Journal Socket.
[ 1.904868] systemd[1]: Starting dracut cmdline hook...
[ 1.905360] systemd[1]: Started Load Kernel Modules.
[ 1.905381] systemd[1]: Starting Setup Virtual Console...
[ 1.905744] systemd[1]: Starting Journal Service...
[ 1.906228] systemd[1]: Started Journal Service.
[ 1.909386] usb 1-3.1.2: new high-speed USB device number 8 using ehci-pci
[ 2.023186] systemd-udevd[224]: starting version 208
[ 2.067429] logitech-djreceiver 0003:046D:C52B.0005: hiddev0,hidraw2: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:1a.7-3.3/input2
[ 2.069132] [drm] Initialized drm 1.1.0 20060810
[ 2.071868] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 2.071878] r8169 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 2.072119] r8169 0000:04:00.0: irq 45 for MSI/MSI-X
[ 2.072369] r8169 0000:04:00.0 eth0: RTL8168b/8111b at 0xffffc90000c7c000, 00:1f:d0:56:44:5a, XID 18000000 IRQ 45
[ 2.072372] r8169 0000:04:00.0 eth0: jumbo features [frames: 4080 bytes, tx checksumming: ko]
[ 2.086055] scsi6 : pata_jmicron
[ 2.088555] scsi7 : pata_jmicron
[ 2.088622] ata7: PATA max UDMA/100 cmd 0xb000 ctl 0xb100 bmdma 0xb400 irq 16
[ 2.088624] ata8: PATA max UDMA/100 cmd 0xb200 ctl 0xb300 bmdma 0xb408 irq 16
[ 2.102121] [drm] radeon kernel modesetting enabled.
[ 2.102477] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x1682:0x3030).
[ 2.102489] [drm] register mmio base: 0xF5000000
[ 2.102491] [drm] register mmio size: 131072
[ 2.102580] ATOM BIOS: CEDAR
[ 2.102630] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[ 2.102632] radeon 0000:01:00.0: GTT: 1024M 0x0000000020000000 - 0x000000005FFFFFFF
[ 2.102634] [drm] Detected VRAM RAM=512M, BAR=256M
[ 2.102636] [drm] RAM width 64bits DDR
[ 2.102744] [TTM] Zone kernel: Available graphics memory: 3055802 kiB
[ 2.102747] [TTM] Zone dma32: Available graphics memory: 2097152 kiB
[ 2.102749] [TTM] Initializing pool allocator
[ 2.102762] [TTM] Initializing DMA pool allocator
[ 2.102783] [drm] radeon: 512M of VRAM memory ready
[ 2.102785] [drm] radeon: 1024M of GTT memory ready.
[ 2.102807] [drm] Loading CEDAR Microcode
[ 2.102899] [drm] Internal thermal controller with fan control
[ 2.120607] input: Logitech Unifying Device. Wireless PID:101d as /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3.3/1-3.3:1.2/0003:046D:C52B.0005/0003:046D:C52B.0006/input/input7
[ 2.120729] logitech-djdevice 0003:046D:C52B.0006: input,hidraw3: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:101d] on usb-0000:00:1a.7-3.3:1
[ 2.122232] logitech-djreceiver 0003:046D:C52B.0005: logi_dj_raw_event: invalid device index:0
[ 2.124023] [drm] radeon: dpm initialized
[ 2.124142] [drm] GART: num cpu pages 262144, num gpu pages 262144
[ 2.153721] [drm] PCIE GART of 1024M enabled (table at 0x000000000025D000).
[ 2.153828] radeon 0000:01:00.0: WB enabled
[ 2.153832] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8801945bbc00
[ 2.153835] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff8801945bbc0c
[ 2.154758] radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x000000000005c418 and cpu addr 0xffffc90004f9c418
[ 2.154762] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.154764] [drm] Driver supports precise vblank timestamp query.
[ 2.154788] radeon 0000:01:00.0: irq 46 for MSI/MSI-X
[ 2.154802] radeon 0000:01:00.0: radeon: using MSI.
[ 2.154827] [drm] radeon: irq initialized.
[ 2.167011] usb 1-3.1.2: New USB device found, idVendor=046d, idProduct=0807
[ 2.167015] usb 1-3.1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=2
[ 2.167017] usb 1-3.1.2: SerialNumber: 6B3A4B80
[ 2.172327] [drm] ring test on 0 succeeded in 1 usecs
[ 2.172386] [drm] ring test on 3 succeeded in 1 usecs
[ 2.242547] ata7.00: ATAPI: Optiarc DVD RW AD-5170A, 1.11, max UDMA/66
[ 2.248625] ata7.00: configured for UDMA/66
[ 2.249774] scsi 6:0:0:0: CD-ROM Optiarc DVD RW AD-5170A 1.11 PQ: 0 ANSI: 5
[ 2.261135] sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
[ 2.261139] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 2.261278] sr 6:0:0:0: Attached scsi CD-ROM sr0
[ 2.261547] sr 6:0:0:0: Attached scsi generic sg1 type 5
[ 2.274018] raid6: sse2x1 4160 MB/s
[ 2.291018] raid6: sse2x2 4980 MB/s
[ 2.308021] raid6: sse2x4 7113 MB/s
[ 2.308023] raid6: using algorithm sse2x4 (7113 MB/s)
[ 2.308024] raid6: using ssse3x2 recovery algorithm
[ 2.309509] xor: measuring software checksum speed
[ 2.319015] prefetch64-sse: 9784.000 MB/sec
[ 2.329015] generic_sse: 8648.000 MB/sec
[ 2.329017] xor: using function: prefetch64-sse (9784.000 MB/sec)
[ 2.346596] Btrfs loaded
[ 2.353315] BTRFS: device label fedora devid 1 transid 149784 /dev/sda4
[ 2.369550] [drm] ring test on 5 succeeded in 1 usecs
[ 2.369555] [drm] UVD initialized successfully.
[ 2.369975] [drm] ib test on ring 0 succeeded in 0 usecs
[ 2.369995] [drm] ib test on ring 3 succeeded in 0 usecs
[ 2.371380] systemd-udevd[234]: renamed network interface eth0 to p21p1
[ 2.541155] Switched to clocksource tsc
[ 2.541496] [drm] ib test on ring 5 succeeded
[ 2.542329] [drm] Radeon Display Connectors
[ 2.542332] [drm] Connector 0:
[ 2.542334] [drm] HDMI-A-1
[ 2.542336] [drm] HPD1
[ 2.542339] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c
[ 2.542341] [drm] Encoders:
[ 2.542343] [drm] DFP1: INTERNAL_UNIPHY1
[ 2.542344] [drm] Connector 1:
[ 2.542346] [drm] DVI-I-1
[ 2.542348] [drm] HPD4
[ 2.542351] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c
[ 2.542352] [drm] Encoders:
[ 2.542354] [drm] DFP2: INTERNAL_UNIPHY
[ 2.542356] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 2.542358] [drm] Connector 2:
[ 2.542365] [drm] VGA-1
[ 2.542367] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[ 2.542368] [drm] Encoders:
[ 2.542369] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[ 2.621134] [drm] fb mappable at 0xE045E000
[ 2.621136] [drm] vram apper at 0xE0000000
[ 2.621137] [drm] size 9437184
[ 2.621139] [drm] fb depth is 24
[ 2.621140] [drm] pitch is 8192
[ 2.621243] fbcon: radeondrmfb (fb0) is primary device
[ 2.687651] Console: switching to colour frame buffer device 210x65
[ 2.692160] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
[ 2.692161] radeon 0000:01:00.0: registered panic notifier
[ 2.699141] [drm] Initialized radeon 2.39.0 20080528 for 0000:01:00.0 on minor 0
[ 2.720518] PM: Starting manual resume from disk
[ 2.720523] PM: Hibernation image partition 8:3 present
[ 2.720524] PM: Looking for hibernation image.
[ 2.720782] PM: Image not found (code -22)
[ 2.720784] PM: Hibernation image not present or could not be loaded.
[ 2.735074] BTRFS info (device sda4): disk space caching is enabled
[ 2.741957] random: nonblocking pool is initialized
[ 6.787149] systemd-journald[115]: Received SIGTERM
[ 8.104373] SELinux: Disabled at runtime.
[ 8.104398] SELinux: Unregistering netfilter hooks
[ 8.131073] audit: type=1404 audit(1411128233.117:2): selinux=0 auid=4294967295 ses=4294967295
[ 10.856835] BTRFS info (device sda4): disk space caching is enabled
[ 11.069041] systemd-udevd[423]: starting version 208
[ 11.810601] RPC: Registered named UNIX socket transport module.
[ 11.810605] RPC: Registered udp transport module.
[ 11.810607] RPC: Registered tcp transport module.
[ 11.810609] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 12.126248] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 13.271657] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 13.296248] parport_pc 00:04: reported by Plug and Play ACPI
[ 13.296291] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[ 13.620800] gameport gameport0: EMU10K1 is pci0000:05:01.1/gameport0, io 0xd100, speed 1009kHz
[ 13.633391] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042f conflicts with OpRegion 0x000000000000042c-0x000000000000042d (\GP2C) (20140424/utaddress-258)
[ 13.633397] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 13.633425] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 13.875786] microcode: CPU0 sig=0x6fb, pf=0x10, revision=0xb6
[ 13.996051] microcode: CPU0 sig=0x6fb, pf=0x10, revision=0xb6
[ 13.997047] microcode: CPU0 updated to revision 0xba, date = 2010-10-03
[ 14.004380] microcode: CPU1 sig=0x6fb, pf=0x10, revision=0xb6
[ 14.004431] microcode: CPU1 sig=0x6fb, pf=0x10, revision=0xb6
[ 14.005429] microcode: CPU1 updated to revision 0xba, date = 2010-10-03
[ 14.010039] microcode: CPU2 sig=0x6fb, pf=0x10, revision=0xb6
[ 14.010201] microcode: CPU2 sig=0x6fb, pf=0x10, revision=0xb6
[ 14.011199] microcode: CPU2 updated to revision 0xba, date = 2010-10-03
[ 14.015775] microcode: CPU3 sig=0x6fb, pf=0x10, revision=0xb6
[ 14.015820] microcode: CPU3 sig=0x6fb, pf=0x10, revision=0xb6
[ 14.016010] microcode: CPU3 updated to revision 0xba, date = 2010-10-03
[ 14.021537] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[ 14.296217] i801_smbus 0000:00:1f.3: SMBus using PCI Interrupt
[ 14.312792] media: Linux media interface: v0.10
[ 14.496397] Linux video capture interface: v2.00
[ 14.683297] ppdev: user-space parallel port driver
[ 14.726036] iTCO_vendor_support: vendor-support=0
[ 14.776076] gpio_ich: GPIO from 195 to 255 on gpio_ich
[ 15.160882] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 15.160922] iTCO_wdt: Found a ICH9 TCO device (Version=2, TCOBASE=0x0460)
[ 15.161107] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 15.177209] coretemp coretemp.0: Using relative temperature scale!
[ 15.177221] coretemp coretemp.0: Using relative temperature scale!
[ 15.177238] coretemp coretemp.0: Using relative temperature scale!
[ 15.177251] coretemp coretemp.0: Using relative temperature scale!
[ 15.974132] usbcore: registered new interface driver ftdi_sio
[ 15.974167] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 15.974273] ftdi_sio 1-3.6:1.0: FTDI USB Serial Device converter detected
[ 15.974305] usb 1-3.6: Detected FT232RL
[ 15.974308] usb 1-3.6: Number of endpoints 2
[ 15.974310] usb 1-3.6: Endpoint 1 MaxPacketSize 64
[ 15.974312] usb 1-3.6: Endpoint 2 MaxPacketSize 64
[ 15.974314] usb 1-3.6: Setting MaxPacketSize 64
[ 15.974679] usb 1-3.6: FTDI USB Serial Device converter now attached to ttyUSB0
[ 15.998248] usb 1-3.1.2: set resolution quirk: cval->res = 384
[ 15.998456] usbcore: registered new interface driver snd-usb-audio
[ 16.065361] snd_hda_intel 0000:00:1b.0: irq 47 for MSI/MSI-X
[ 16.065491] snd_hda_intel 0000:01:00.1: Handle VGA-switcheroo audio client
[ 16.065518] snd_hda_intel 0000:01:00.1: irq 48 for MSI/MSI-X
[ 16.197505] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card2/input8
[ 16.279695] sound hdaudioC1D2: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[ 16.279699] sound hdaudioC1D2: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 16.279702] sound hdaudioC1D2: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[ 16.279704] sound hdaudioC1D2: mono: mono_out=0x0
[ 16.279706] sound hdaudioC1D2: dig-out=0x1e/0x0
[ 16.279708] sound hdaudioC1D2: inputs:
[ 16.279710] sound hdaudioC1D2: Front Mic=0x19
[ 16.279713] sound hdaudioC1D2: Rear Mic=0x18
[ 16.279715] sound hdaudioC1D2: Line=0x1a
[ 16.294685] input: HDA Intel Front Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9
[ 16.294799] input: HDA Intel Rear Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
[ 16.294881] input: HDA Intel Line as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
[ 16.294961] input: HDA Intel Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card1/input12
[ 16.295081] input: HDA Intel Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input13
[ 16.561732] uvcvideo: Found UVC 1.00 device <unnamed> (046d:0807)
[ 16.576059] input: UVC Camera (046d:0807) as /devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3.1/1-3.1.2/1-3.1.2:1.0/input/input14
[ 16.576140] usbcore: registered new interface driver uvcvideo
[ 16.576142] USB Video Class driver (1.1.1)
[ 16.725116] Adding 6176764k swap on /dev/sda3. Priority:-1 extents:1 across:6176764k FS
[ 17.725899] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
[ 17.856515] systemd-journald[391]: Received request to flush runtime journal from PID 1
[ 32.115703] systemd-journald[391]: File /var/log/journal/33aba2f998724b749ad320df8c6e6bad/system.journal corrupted or uncleanly shut down, renaming and replacing.
[ 38.432343] audit: type=1305 audit(1411128263.418:3): audit_pid=581 old=0 auid=4294967295 ses=4294967295 res=1
[ 39.249048] systemd[1]: Unit rngd.service entered failed state.
[ 40.473293] cfg80211: Calling CRDA to update world regulatory domain
[ 40.476419] cfg80211: World regulatory domain updated:
[ 40.476422] cfg80211: DFS Master region: unset
[ 40.476424] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time)
[ 40.476427] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 40.476429] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A)
[ 40.476432] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A)
[ 40.476434] cfg80211: (5170000 KHz - 5250000 KHz @ 160000 KHz), (N/A, 2000 mBm), (N/A)
[ 40.476436] cfg80211: (5250000 KHz - 5330000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 40.476439] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s)
[ 40.476441] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A)
[ 40.476443] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A)
[ 56.281314] r8169 0000:04:00.0 p21p1: link down
[ 56.281340] r8169 0000:04:00.0 p21p1: link down
[ 56.281347] IPv6: ADDRCONF(NETDEV_UP): p21p1: link is not ready
[ 57.316269] Bluetooth: Core ver 2.19
[ 57.316293] NET: Registered protocol family 31
[ 57.316295] Bluetooth: HCI device and connection manager initialized
[ 57.316306] Bluetooth: HCI socket layer initialized
[ 57.316309] Bluetooth: L2CAP socket layer initialized
[ 57.316319] Bluetooth: SCO socket layer initialized
[ 57.825325] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 57.825329] Bluetooth: BNEP filters: protocol multicast
[ 57.825339] Bluetooth: BNEP socket layer initialized
[ 59.112679] r8169 0000:04:00.0 p21p1: link up
[ 59.112691] IPv6: ADDRCONF(NETDEV_CHANGE): p21p1: link becomes ready
[ 60.189592] Ebtables v2.0 registered
[ 60.891622] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 65.333963] systemd-journald[391]: File /var/log/journal/33aba2f998724b749ad320df8c6e6bad/user-42.journal corrupted or uncleanly shut down, renaming and replacing.
[ 65.933805] Bridge firewalling registered
[ 66.026840] tun: Universal TUN/TAP device driver, 1.6
[ 66.026845] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 66.058201] device virbr0-nic entered promiscuous mode
[ 66.734177] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 67.224627] virbr0: port 1(virbr0-nic) entered listening state
[ 67.224637] virbr0: port 1(virbr0-nic) entered listening state
[ 67.224680] IPv6: ADDRCONF(NETDEV_UP): virbr0: link is not ready
[ 68.077329] virbr0: port 1(virbr0-nic) entered disabled state
[ 68.736097] logitech-djreceiver 0003:046D:C52B.0005: logi_dj_raw_event: invalid device index:255
[ 68.738263] logitech-djreceiver 0003:046D:C52B.0005: logi_dj_raw_event: invalid device index:255
[ 68.740427] logitech-djreceiver 0003:046D:C52B.0005: logi_dj_raw_event: invalid device index:255
[ 85.593853] systemd-journald[391]: File /var/log/journal/33aba2f998724b749ad320df8c6e6bad/user-500.journal corrupted or uncleanly shut down, renaming and replacing.
[ 90.557729] fuse init (API version 7.23)
[ 169.516483] bash (1563): drop_caches: 3
[ 184.652125] bash (1563): drop_caches: 3
[ 191.200194] bash (1563): drop_caches: 3
[ 200.113181] bash (1563): drop_caches: 3
[ 225.702247] bash (1563): drop_caches: 3
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance Issues
2014-09-19 12:18 Performance Issues Rob Spanton
@ 2014-09-19 12:25 ` Swâmi Petaramesh
2014-09-19 12:58 ` Austin S Hemmelgarn
2014-09-19 12:49 ` Austin S Hemmelgarn
` (3 subsequent siblings)
4 siblings, 1 reply; 29+ messages in thread
From: Swâmi Petaramesh @ 2014-09-19 12:25 UTC (permalink / raw)
To: rob; +Cc: linux-btrfs
Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit :
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs.
Weeelll I have the same over-complicated kind of setup, and an Arch Linux
BTRFS system which used to boot in some decent amout of time in the past now
takes about 5 full minutes to just make it to the KDM login prompt, and
another 5 minutes before KDE is fully started. Makes me think of the good ole'
times of Windows 95 OSR2 on a 486SX with a dying 1 GB Hard disk...
Now, let me add that I had removed all snaphots, ran a full defrag, and even
rebalanced the damn thing without any positive effect...
(And yes, my HD is physically in good shape, SMART feels fully happy, and it's
less than 75% full...)
I've been using BTRFS for 2-3 years on a dozen of different systems, and if
something doesn't surprise me at all, it's « slow performance », indeed,
although I'm myself more accustomed to « incredibly fscking damn slow
performance »...
HTH
--
Swâmi Petaramesh <swami@petaramesh.org> http://petaramesh.org PGP 9076E32E
Un homme ne doit pas avaler plus de bobards qu'il ne peut en digérer.
-- Henry Brooks Adams
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance Issues
2014-09-19 12:25 ` Swâmi Petaramesh
@ 2014-09-19 12:58 ` Austin S Hemmelgarn
0 siblings, 0 replies; 29+ messages in thread
From: Austin S Hemmelgarn @ 2014-09-19 12:58 UTC (permalink / raw)
To: Swâmi Petaramesh, rob; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]
On 2014-09-19 08:25, Swâmi Petaramesh wrote:
> Le vendredi 19 septembre 2014, 13:18:34 Rob Spanton a écrit :
>> I have a particularly uncomplicated setup (a desktop PC with a hard
>> disk) and I'm seeing particularly slow performance from btrfs.
>
> Weeelll I have the same over-complicated kind of setup, and an Arch Linux
> BTRFS system which used to boot in some decent amout of time in the past now
> takes about 5 full minutes to just make it to the KDM login prompt, and
> another 5 minutes before KDE is fully started. Makes me think of the good ole'
> times of Windows 95 OSR2 on a 486SX with a dying 1 GB Hard disk...
Well, part of your problem might be KDE itself, it's extremely CPU
intensive these days. I'd suggest disabling the 'semantic desktop'
stuff, because that tends to be the worst offender as far as soaking up
system resources. Also, if you recently switched to systemd, that may
be causing some slowdown as well (journald's default settings are
terrible for performance)
>
> Now, let me add that I had removed all snaphots, ran a full defrag, and even
> rebalanced the damn thing without any positive effect...
>
> (And yes, my HD is physically in good shape, SMART feels fully happy, and it's
> less than 75% full...)
>
> I've been using BTRFS for 2-3 years on a dozen of different systems, and if
> something doesn't surprise me at all, it's « slow performance », indeed,
> although I'm myself more accustomed to « incredibly fscking damn slow
> performance »...
It's kind of funny, but I haven't had any performance issues with BTRFS
since about 3.10, even on the systems my employer is using Fedora 20 on,
and those use only a Core 2 Duo Processor, DDR2-800 RAM, and SATA2 hard
drives.
> HTH
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 12:18 Performance Issues Rob Spanton
2014-09-19 12:25 ` Swâmi Petaramesh
@ 2014-09-19 12:49 ` Austin S Hemmelgarn
2014-09-19 12:59 ` Austin S Hemmelgarn
2014-09-19 13:34 ` Holger Hoffstätte
` (2 subsequent siblings)
4 siblings, 1 reply; 29+ messages in thread
From: Austin S Hemmelgarn @ 2014-09-19 12:49 UTC (permalink / raw)
To: rob, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
On 2014-09-19 08:18, Rob Spanton wrote:
> Hi,
>
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s. My
> mail client (evolution) also seems to perform particularly poorly on
> this setup, and my hunch is that it's spending a lot of time waiting on
> the filesystem.
>
> I've tried mounting with noatime, and this has had no effect. Anyone
> got any ideas?
>
> Here are the things that the wiki page asked for [1]:
>
> uname -a:
>
> Linux zarniwoop.blob 3.16.2-200.fc20.x86_64 #1 SMP Mon Sep 8
> 11:54:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> btrfs --version:
>
> Btrfs v3.16
>
> btrfs fi show:
>
> Label: 'fedora' uuid: 717c0a1b-815c-4e6a-86c0-60b921e84d75
> Total devices 1 FS bytes used 1.49TiB
> devid 1 size 2.72TiB used 1.50TiB path /dev/sda4
>
> Btrfs v3.16
>
> btrfs fi df /:
>
> Data, single: total=1.48TiB, used=1.48TiB
> System, DUP: total=32.00MiB, used=208.00KiB
> Metadata, DUP: total=11.50GiB, used=10.43GiB
> unknown, single: total=512.00MiB, used=0.00
>
> dmesg dump is attached.
>
> Please CC any responses to me, as I'm not subscribed to the list.
>
> Cheers,
>
> Rob
>
> [1] https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list
>
>
WRT the performance of Evolution, the issue is probably fragmentation of
the data files. If you run the command:
# btrfs fi defrag -rv /home
you should see some improvement in evolution performance (until you get
any new mail that is). Evolution (like most graphical e-mail clients
these days) uses sqlite for data storage, and sqlite database files are
one of the known pathological cases for COW filesystems in general; the
solution is to mark the files as NOCOW (see the info about VM images in
[1] and [2], the same suggestions apply to database files).
As for git, I haven't seen any performance issues specific to BTRFS; are
you using any compress= mount option? zlib based compression is known to
cause serious slowdowns. I don't think that git uses any kind of
database for data storage. Also, if the performance comparison is from
other systems, unless those systems have the EXACT same hardware
configuration, they aren't really a good comparison. Unless the pc this
is on is a relatively recent system (less than a year or two old), it
may just be hardware that is the performance bottleneck.
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance Issues
2014-09-19 12:49 ` Austin S Hemmelgarn
@ 2014-09-19 12:59 ` Austin S Hemmelgarn
0 siblings, 0 replies; 29+ messages in thread
From: Austin S Hemmelgarn @ 2014-09-19 12:59 UTC (permalink / raw)
To: rob, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]
On 2014-09-19 08:49, Austin S Hemmelgarn wrote:
> On 2014-09-19 08:18, Rob Spanton wrote:
>> Hi,
>>
>> I have a particularly uncomplicated setup (a desktop PC with a hard
>> disk) and I'm seeing particularly slow performance from btrfs. A `git
>> status` in the linux source tree takes about 46 seconds after dropping
>> caches, whereas on other machines using ext4 this takes about 13s. My
>> mail client (evolution) also seems to perform particularly poorly on
>> this setup, and my hunch is that it's spending a lot of time waiting on
>> the filesystem.
>>
>> I've tried mounting with noatime, and this has had no effect. Anyone
>> got any ideas?
>>
>> Here are the things that the wiki page asked for [1]:
>>
>> uname -a:
>>
>> Linux zarniwoop.blob 3.16.2-200.fc20.x86_64 #1 SMP Mon Sep 8
>> 11:54:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> btrfs --version:
>>
>> Btrfs v3.16
>>
>> btrfs fi show:
>>
>> Label: 'fedora' uuid: 717c0a1b-815c-4e6a-86c0-60b921e84d75
>> Total devices 1 FS bytes used 1.49TiB
>> devid 1 size 2.72TiB used 1.50TiB path /dev/sda4
>>
>> Btrfs v3.16
>>
>> btrfs fi df /:
>>
>> Data, single: total=1.48TiB, used=1.48TiB
>> System, DUP: total=32.00MiB, used=208.00KiB
>> Metadata, DUP: total=11.50GiB, used=10.43GiB
>> unknown, single: total=512.00MiB, used=0.00
>>
>> dmesg dump is attached.
>>
>> Please CC any responses to me, as I'm not subscribed to the list.
>>
>> Cheers,
>>
>> Rob
>>
>> [1] https://btrfs.wiki.kernel.org/index.php/Btrfs_mailing_list
>>
>>
> WRT the performance of Evolution, the issue is probably fragmentation of
> the data files. If you run the command:
> # btrfs fi defrag -rv /home
> you should see some improvement in evolution performance (until you get
> any new mail that is). Evolution (like most graphical e-mail clients
> these days) uses sqlite for data storage, and sqlite database files are
> one of the known pathological cases for COW filesystems in general; the
> solution is to mark the files as NOCOW (see the info about VM images in
> [1] and [2], the same suggestions apply to database files).
>
> As for git, I haven't seen any performance issues specific to BTRFS; are
> you using any compress= mount option? zlib based compression is known to
> cause serious slowdowns. I don't think that git uses any kind of
> database for data storage. Also, if the performance comparison is from
> other systems, unless those systems have the EXACT same hardware
> configuration, they aren't really a good comparison. Unless the pc this
> is on is a relatively recent system (less than a year or two old), it
> may just be hardware that is the performance bottleneck.
>
Realized after I sent this that I forgot the links for [1] and [2]
[1] https://btrfs.wiki.kernel.org/index.php/UseCases
[2] https://btrfs.wiki.kernel.org/index.php/FAQ
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 12:18 Performance Issues Rob Spanton
2014-09-19 12:25 ` Swâmi Petaramesh
2014-09-19 12:49 ` Austin S Hemmelgarn
@ 2014-09-19 13:34 ` Holger Hoffstätte
2014-09-22 11:59 ` David Sterba
2014-09-19 13:51 ` Holger Hoffstätte
2014-09-19 15:05 ` Josef Bacik
4 siblings, 1 reply; 29+ messages in thread
From: Holger Hoffstätte @ 2014-09-19 13:34 UTC (permalink / raw)
To: linux-btrfs
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s. My
This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
whatever you want to call it. git relies a lot on fast stat() calls,
and those seem to be particularly slow with btrfs esp. on rotational
media. I have the same problem with rsync on a freshly mounted volume;
it gets fast (quite so!) after the first run.
The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all
file inodes.
I'd also love a technical explanation why this happens and how it could
be fixed. Maybe it's just a consequence of how the metadata tree(s)
are laid out on disk.
> I've tried mounting with noatime, and this has had no effect. Anyone
> got any ideas?
Don't drop the caches :-)
-h
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 13:34 ` Holger Hoffstätte
@ 2014-09-22 11:59 ` David Sterba
2014-09-22 12:37 ` Holger Hoffstätte
0 siblings, 1 reply; 29+ messages in thread
From: David Sterba @ 2014-09-22 11:59 UTC (permalink / raw)
To: Holger Hoffstätte; +Cc: linux-btrfs
On Fri, Sep 19, 2014 at 01:34:38PM +0000, Holger Hoffstätte wrote:
> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>
> > I have a particularly uncomplicated setup (a desktop PC with a hard
> > disk) and I'm seeing particularly slow performance from btrfs. A `git
> > status` in the linux source tree takes about 46 seconds after dropping
> > caches, whereas on other machines using ext4 this takes about 13s. My
>
> This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
> whatever you want to call it. git relies a lot on fast stat() calls,
> and those seem to be particularly slow with btrfs esp. on rotational
> media. I have the same problem with rsync on a freshly mounted volume;
> it gets fast (quite so!) after the first run.
>
> The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all
> file inodes.
>
> I'd also love a technical explanation why this happens and how it could
> be fixed. Maybe it's just a consequence of how the metadata tree(s)
> are laid out on disk.
The stat() call is the most severe slowdown factor in combination with
fragmentation and random order of the inodes that are being stat()ed.
A 'ls -f' (that does not stat) goes only through the DIR_INDEX_KEY items
in the b-tree that are usually packed together and reading is sequential
and fast.
A 'ls' that calls stat() in turn will have to seek for the INODE_ITEM
item that can be far from all the currently read metadata blocks.
What could help here is a directory readahead, pre-read the inode items
during the readdir() call. I tried this with current readahead (some
timeago) code but this didn't lead to improvement. The reason is that
the readahead has low priority and is not able to cache the metadata
blocks in time.
So the fix or rather workaround is to implement high priority readahead
and trigger it for all DIR_INDEX keys that get returned by readdir().
This will hurt the 'ls -f' usecase.
In your example, 'du -s' acts as the readahead step.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-22 11:59 ` David Sterba
@ 2014-09-22 12:37 ` Holger Hoffstätte
2014-09-22 13:25 ` David Sterba
0 siblings, 1 reply; 29+ messages in thread
From: Holger Hoffstätte @ 2014-09-22 12:37 UTC (permalink / raw)
To: linux-btrfs
On Mon, 22 Sep 2014 13:59:03 +0200, David Sterba wrote:
> On Fri, Sep 19, 2014 at 01:34:38PM +0000, Holger Hoffstätte wrote:
>>
>> I'd also love a technical explanation why this happens and how it could
>> be fixed. Maybe it's just a consequence of how the metadata tree(s)
>> are laid out on disk.
>
> The stat() call is the most severe slowdown factor in combination with
> fragmentation and random order of the inodes that are being stat()ed.
>
> A 'ls -f' (that does not stat) goes only through the DIR_INDEX_KEY items
> in the b-tree that are usually packed together and reading is sequential
> and fast.
>
> A 'ls' that calls stat() in turn will have to seek for the INODE_ITEM
> item that can be far from all the currently read metadata blocks.
Thanks Dave - that confirms everything I (unscientifically ;) observed so
far, since I also tried to use "find" to warm up (in the hope it would
cache the relevant metadata blocks), but running with strace showed that
it does - of course! - not call stat on each inode, and just quickly reads
the directory entry list (via getdents()).
This meant that even after a full "find" a subsequent "du" would still be
slow(er). Both the cold "find" and a cold "du" also *sound* noticeably
different, in terms of disk head scratching; find is significantly less
seeky.
Interesting that you also mention the readahead. I've run the "du" warmup
under Brendan Gregg's iosnoop and it shows that most stat()-heavy I/O is
done in 16k blocks, while ext4 only seems to use 4k.
Time to look at the trees in detail.. :)
-h
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-22 12:37 ` Holger Hoffstätte
@ 2014-09-22 13:25 ` David Sterba
0 siblings, 0 replies; 29+ messages in thread
From: David Sterba @ 2014-09-22 13:25 UTC (permalink / raw)
To: Holger Hoffstätte; +Cc: linux-btrfs
On Mon, Sep 22, 2014 at 12:37:59PM +0000, Holger Hoffstätte wrote:
> Thanks Dave - that confirms everything I (unscientifically ;) observed so
> far, since I also tried to use "find" to warm up (in the hope it would
> cache the relevant metadata blocks), but running with strace showed that
> it does - of course! - not call stat on each inode, and just quickly reads
> the directory entry list (via getdents()).
>
> This meant that even after a full "find" a subsequent "du" would still be
> slow(er). Both the cold "find" and a cold "du" also *sound* noticeably
> different, in terms of disk head scratching; find is significantly less
> seeky.
The default find still calls some variant of stat quite a lot because it
needs to decide whether to recurse to the directories, but when compared
to 'du -s' it's still not called for all files.
> Interesting that you also mention the readahead. I've run the "du" warmup
> under Brendan Gregg's iosnoop and it shows that most stat()-heavy I/O is
> done in 16k blocks, while ext4 only seems to use 4k.
Most probably, 16k is the size of the metadata blocks, mkfs option
--nodesize or default since progs v3.12.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 12:18 Performance Issues Rob Spanton
` (2 preceding siblings ...)
2014-09-19 13:34 ` Holger Hoffstätte
@ 2014-09-19 13:51 ` Holger Hoffstätte
2014-09-19 14:53 ` Austin S Hemmelgarn
` (2 more replies)
2014-09-19 15:05 ` Josef Bacik
4 siblings, 3 replies; 29+ messages in thread
From: Holger Hoffstätte @ 2014-09-19 13:51 UTC (permalink / raw)
To: linux-btrfs
On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s. My
> mail client (evolution) also seems to perform particularly poorly on
> this setup, and my hunch is that it's spending a lot of time waiting on
> the filesystem.
This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
whatever you want to call it. git relies a lot on fast stat() calls,
and those seem to be particularly slow with btrfs esp. on rotational
media. I have the same problem with rsync on a freshly mounted volume;
it gets fast (quite so!) after the first run.
The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all
file inodes.
I'd also love a technical explanation why this happens and how it could
be fixed. Maybe it's just a consequence of how the metadata tree(s)
are laid out on disk.
> I've tried mounting with noatime, and this has had no effect. Anyone
> got any ideas?
Don't drop the caches :-)
-h
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance Issues
2014-09-19 13:51 ` Holger Hoffstätte
@ 2014-09-19 14:53 ` Austin S Hemmelgarn
2014-09-19 16:23 ` Holger Hoffstätte
2014-09-19 17:51 ` Zach Brown
2014-09-20 8:23 ` Marc Dietrich
2 siblings, 1 reply; 29+ messages in thread
From: Austin S Hemmelgarn @ 2014-09-19 14:53 UTC (permalink / raw)
To: Holger Hoffstätte, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]
On 2014-09-19 09:51, Holger Hoffstätte wrote:
>
> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>
>> I have a particularly uncomplicated setup (a desktop PC with a hard
>> disk) and I'm seeing particularly slow performance from btrfs. A `git
>> status` in the linux source tree takes about 46 seconds after dropping
>> caches, whereas on other machines using ext4 this takes about 13s. My
>> mail client (evolution) also seems to perform particularly poorly on
>> this setup, and my hunch is that it's spending a lot of time waiting on
>> the filesystem.
>
> This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
> whatever you want to call it. git relies a lot on fast stat() calls,
> and those seem to be particularly slow with btrfs esp. on rotational
> media. I have the same problem with rsync on a freshly mounted volume;
> it gets fast (quite so!) after the first run.
I find that kind of funny, because regardless of filesystem, stat() is
one of the *slowest* syscalls on almost every *nix system in existence.
>
> The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all
> file inodes.
>
> I'd also love a technical explanation why this happens and how it could
> be fixed. Maybe it's just a consequence of how the metadata tree(s)
> are laid out on disk.
While I don't know for certain, I think it's largely just a side effect
of the lack of performance tuning in the BTRFS code.
>
>> I've tried mounting with noatime, and this has had no effect. Anyone
>> got any ideas?
>
> Don't drop the caches :-)
>
> -h
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 14:53 ` Austin S Hemmelgarn
@ 2014-09-19 16:23 ` Holger Hoffstätte
0 siblings, 0 replies; 29+ messages in thread
From: Holger Hoffstätte @ 2014-09-19 16:23 UTC (permalink / raw)
To: linux-btrfs
On Fri, 19 Sep 2014 10:53:03 -0400, Austin S Hemmelgarn wrote:
> I find that kind of funny, because regardless of filesystem, stat() is
> one of the *slowest* syscalls on almost every *nix system in existence.
Sure. I didn't mean to imply that stat() in its various incarnations is
fast by itself, just that git relies a lot on it since it necessarily needs
to look at every file.
-h
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 13:51 ` Holger Hoffstätte
2014-09-19 14:53 ` Austin S Hemmelgarn
@ 2014-09-19 17:51 ` Zach Brown
2014-09-20 8:23 ` Marc Dietrich
2 siblings, 0 replies; 29+ messages in thread
From: Zach Brown @ 2014-09-19 17:51 UTC (permalink / raw)
To: Holger Hoffstätte; +Cc: linux-btrfs
On Fri, Sep 19, 2014 at 01:51:22PM +0000, Holger Hoffstätte wrote:
>
> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>
> > I have a particularly uncomplicated setup (a desktop PC with a hard
> > disk) and I'm seeing particularly slow performance from btrfs. A `git
> > status` in the linux source tree takes about 46 seconds after dropping
> > caches, whereas on other machines using ext4 this takes about 13s. My
> > mail client (evolution) also seems to perform particularly poorly on
> > this setup, and my hunch is that it's spending a lot of time waiting on
> > the filesystem.
>
> This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
> whatever you want to call it. git relies a lot on fast stat() calls,
> and those seem to be particularly slow with btrfs esp. on rotational
> media. I have the same problem with rsync on a freshly mounted volume;
> it gets fast (quite so!) after the first run.
>
> The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all
> file inodes.
>
> I'd also love a technical explanation why this happens and how it could
> be fixed. Maybe it's just a consequence of how the metadata tree(s)
> are laid out on disk.
There's a lot of meat behind that "just a consequence" but, yes, that's
the heart of it. Different metadata designs result in different io
patterns which single rotating drives are exquisitely sensitive to.
You can look for differences in io patterns with iostat, blktrace,
iowatcher, etc. They'll show differences in io sizes, concurrency,
locality, and often differences in the amount of blocks of data read.
http://masoncoding.com/iowatcher/
As for "fixing it", welllll, it's arguably working as intended. If you
turned btrfs from one cow tree into lots of journaled trees of trees
then, well, we'd be left with an absurd reimplementation of ext*|xfs.
- z
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 13:51 ` Holger Hoffstätte
2014-09-19 14:53 ` Austin S Hemmelgarn
2014-09-19 17:51 ` Zach Brown
@ 2014-09-20 8:23 ` Marc Dietrich
2014-09-20 13:41 ` Martin
2014-09-20 14:04 ` Wang Shilong
2 siblings, 2 replies; 29+ messages in thread
From: Marc Dietrich @ 2014-09-20 8:23 UTC (permalink / raw)
To: Holger Hoffstätte; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte:
>
> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>
> > I have a particularly uncomplicated setup (a desktop PC with a hard
> > disk) and I'm seeing particularly slow performance from btrfs. A `git
> > status` in the linux source tree takes about 46 seconds after dropping
> > caches, whereas on other machines using ext4 this takes about 13s. My
> > mail client (evolution) also seems to perform particularly poorly on
> > this setup, and my hunch is that it's spending a lot of time waiting on
> > the filesystem.
>
> This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
> whatever you want to call it. git relies a lot on fast stat() calls,
> and those seem to be particularly slow with btrfs esp. on rotational
> media. I have the same problem with rsync on a freshly mounted volume;
> it gets fast (quite so!) after the first run.
my favorite benchmark is "ls -l /usr/bin":
ext4: 0.934s
btrfs: 21.814s
also mounting large partitons (several 100Gs) takes lot of time on btrfs.
Better to defer it during boot using e.g. "noauto,x-systemd.automount".
Marc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-20 8:23 ` Marc Dietrich
@ 2014-09-20 13:41 ` Martin
2014-09-20 18:29 ` Chris Murphy
2014-09-20 14:04 ` Wang Shilong
1 sibling, 1 reply; 29+ messages in thread
From: Martin @ 2014-09-20 13:41 UTC (permalink / raw)
To: linux-btrfs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 20/09/14 09:23, Marc Dietrich wrote:
> Am Freitag, 19. September 2014, 13:51:22 schrieb Holger
> Hoffstätte:
>>
>> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>>
>>> I have a particularly uncomplicated setup (a desktop PC with a
>>> hard disk) and I'm seeing particularly slow performance from
>>> btrfs. A `git status` in the linux source tree takes about 46
>>> seconds after dropping caches, whereas on other machines using
>>> ext4 this takes about 13s. My mail client (evolution) also
>>> seems to perform particularly poorly on this setup, and my
>>> hunch is that it's spending a lot of time waiting on the
>>> filesystem.
>>
>> This is - unfortunately - a particular btrfs
>> oddity/characteristic/flaw, whatever you want to call it. git
>> relies a lot on fast stat() calls, and those seem to be
>> particularly slow with btrfs esp. on rotational media. I have the
>> same problem with rsync on a freshly mounted volume; it gets fast
>> (quite so!) after the first run.
>
> my favorite benchmark is "ls -l /usr/bin":
>
> ext4: 0.934s btrfs: 21.814s
So... On my old low power slow Atom SSD ext4 system:
time ls -l /usr/bin
real 0m0.369s
user 0m0.048s
sys 0m0.128s
Repeated:
real 0m0.107s
user 0m0.040s
sys 0m0.044s
and that is for:
# ls -l /usr/bin | wc
1384 13135 88972
On a comparatively super dual core Athlon64 SSD btrfs three disk btrfs
raid1 system:
real 0m0.103s
user 0m0.004s
sys 0m0.040s
Repeated:
real 0m0.027s
user 0m0.008s
sys 0m0.012s
For:
# ls -l /usr/bin | wc
1449 13534 89024
And on an identical comparatively super dual core Athlon64 HDD
'spinning rust' btrfs two disk btrfs raid1 system:
real 0m0.101s
user 0m0.008s
sys 0m0.020s
Repeated:
real 0m0.020s
user 0m0.004s
sys 0m0.012s
For:
# ls -l /usr/bin | wc
1161 10994 79350
So, no untoward concerns there.
Marc:
You on something really ancient and hopelessly fragmented into oblivion?
> also mounting large partitons (several 100Gs) takes lot of time on
> btrfs.
I've noticed that also for some 16TB btrfs raid1 mounts, btrfs is not
as fast as mounting ext4 but then again all very much faster than
mounting ext4 when a fsck count is tripped!...
So, nothing untoward there.
For my usage, controlling fragmentation and having some automatic
mechanism to deal with pathological fragmentation with such as sqlite
files are greater concerns!
(Yes, there is the manual fix of NOCOW... I also put such horrors into
tmpfs and snapshot that... All well and good but all unnecessary admin
tasks!)
Regards,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlQdhBwACgkQ+sI3Ds7h07f/VwCgkHPjrIkBkWh5zrKwvN7fXalZ
LWcAoIbLFEoc7iTNLzgSChNvnYatIkuZ
=YlDI
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-20 13:41 ` Martin
@ 2014-09-20 18:29 ` Chris Murphy
0 siblings, 0 replies; 29+ messages in thread
From: Chris Murphy @ 2014-09-20 18:29 UTC (permalink / raw)
To: Btrfs BTRFS
On Sep 20, 2014, at 7:41 AM, Martin <m_btrfs@ml1.co.uk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 20/09/14 09:23, Marc Dietrich wrote:
>> Am Freitag, 19. September 2014, 13:51:22 schrieb Holger
>> Hoffstätte:
>>>
>>> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>>>
>>>> I have a particularly uncomplicated setup (a desktop PC with a
>>>> hard disk) and I'm seeing particularly slow performance from
>>>> btrfs. A `git status` in the linux source tree takes about 46
>>>> seconds after dropping caches, whereas on other machines using
>>>> ext4 this takes about 13s. My mail client (evolution) also
>>>> seems to perform particularly poorly on this setup, and my
>>>> hunch is that it's spending a lot of time waiting on the
>>>> filesystem.
>>>
>>> This is - unfortunately - a particular btrfs
>>> oddity/characteristic/flaw, whatever you want to call it. git
>>> relies a lot on fast stat() calls, and those seem to be
>>> particularly slow with btrfs esp. on rotational media. I have the
>>> same problem with rsync on a freshly mounted volume; it gets fast
>>> (quite so!) after the first run.
>>
>> my favorite benchmark is "ls -l /usr/bin":
>>
>> ext4: 0.934s btrfs: 21.814s
>
>
> So... On my old low power slow Atom SSD ext4 system:
[snip]
> On a comparatively super dual core Athlon64 SSD btrfs three disk btrfs
> raid1 system:
[snip]
Yeah between XFS and Btrfs in the same VM I'm not seeing anything like Marc's numbers. Both fs's are newish but have been significantly updated, and the Btrfs one has a pile of debuginfo rpms installed.
XFS:
time mount /mnt/xfs
time ls -l /mnt/xfs/usr/bin
real 0m0.205s
ls -l /mnt/xfs/usr/bin | wc
1625 14978 100833
Btrfs:
time mount /mnt/btrfs
time ls -l /mnt/btrfs/usr/bin
real 0m0.482s
ls -l /mnt/btrfs/usr/bin | wc
1817 16724 110364
XFS:
time tree -al /mnt/xfs/usr
14050 dirs, 193464 files
real 18.336
Btrfs:
time tree -al /mnt/btrfs/usr
15552 dirs, 165958 files
real 21.029s
> (Yes, there is the manual fix of NOCOW... I also put such horrors into
> tmpfs and snapshot that... All well and good but all unnecessary admin
> tasks!)
This is kinda interesting. 20 lines of code.
http://blog.delphix.com/uday/2013/02/19/78/
I'm curious what pathologies it'd reveal in Btrfs, but also say XFS on LVM thinp with and without snapshots.
Chris Murphy
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-20 8:23 ` Marc Dietrich
2014-09-20 13:41 ` Martin
@ 2014-09-20 14:04 ` Wang Shilong
2014-09-20 20:44 ` Marc Dietrich
1 sibling, 1 reply; 29+ messages in thread
From: Wang Shilong @ 2014-09-20 14:04 UTC (permalink / raw)
To: Marc Dietrich; +Cc: Holger Hoffstätte, linux-btrfs
Hi,
just my two cents here.^_^
> Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte:
>>
>> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
>>
>>> I have a particularly uncomplicated setup (a desktop PC with a hard
>>> disk) and I'm seeing particularly slow performance from btrfs. A `git
>>> status` in the linux source tree takes about 46 seconds after dropping
>>> caches, whereas on other machines using ext4 this takes about 13s. My
>>> mail client (evolution) also seems to perform particularly poorly on
>>> this setup, and my hunch is that it's spending a lot of time waiting on
>>> the filesystem.
>>
>> This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
>> whatever you want to call it. git relies a lot on fast stat() calls,
>> and those seem to be particularly slow with btrfs esp. on rotational
>> media. I have the same problem with rsync on a freshly mounted volume;
>> it gets fast (quite so!) after the first run.
>
> my favorite benchmark is "ls -l /usr/bin":
>
> ext4: 0.934s
> btrfs: 21.814s
I did a quick benchmark for this:
Testing tool is something like follows, it create 50W files
and 50w directories under a fresh mkfs filesystem, btrfs is just
a little slower than ext4:
For ext4:
real 0m9.295s
user 0m2.252s
sys 0m7.010s
For btrfs:
real 0m10.207s
user 0m1.347s
sys 0m8.353s
And test is done with a 20G vm disk(backend is hard disk) with
latest kernel compiled under VM.
#!/bin/bash
umount /dev/sdc
#~/source/e2fsprogs/misc/mke2fs -F -O inline_data /dev/sdc >/dev/null
mkfs.ext4 -F /dev/sdc >/dev/null
mount /dev/sdc /mnt
./mdtest -d /mnt/ext4 -n 500000 -C >&/dev/null
echo 3 > /proc/sys/vm/drop_caches
time ls -l /mnt/ext4/\#test-dir.0/mdtest_tree.0 >& /dev/null
umount /dev/sdc
mkfs.btrfs -f /dev/sdc >/dev/null
mount /dev/sdc /mnt
./mdtest -d /mnt/btrfs -n 500000 -C >/dev/null
echo 3 > /proc/sys/vm/drop_caches
time ls -l /mnt/btrfs/\#test-dir.0/mdtest_tree.0 >& /dev/null
So here i think Btrfs is not that you think much slower than Ext4 at least
for ‘ls’ which means directory reading performances…
Here i think you could do several ways to improve or avoid such things:
1. create a separate subvolume or separate partition for /usr and use noatime
mount option if possible.(I remembered Marc MARLIEN gave some good example for this)
2. running defrag command to reduce fragmentation.
Reasons for doing these are because that directory like /usr/bin is regularly accessed
which will also trigger Btrfs widely COWed which may cause serious fragmentation
and that may cause some bad performances..
And another factor btrfs in default all files are mixed together in a a fs
B-tree, which means that all read/write lock will walk through same tree which
may cause some lock contention problem.
So use a separate subvoulme tree could improve lock thing a bit for that IMO.
BTW, next time if someone reported some problems,it will be nice to
give your detailed information for example kernel version, how many subvolumes/snapshots,
btrfs file system configurations, usage(running btrfs file show,btrfs file df e.g.)
these informations are useful for others to reproduce and analysis...
>
> also mounting large partitons (several 100Gs) takes lot of time on btrfs.
> Better to defer it during boot using e.g. "noauto,x-systemd.automount".
>
> Marc
Best Regards,
Wang Shilong
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-20 14:04 ` Wang Shilong
@ 2014-09-20 20:44 ` Marc Dietrich
0 siblings, 0 replies; 29+ messages in thread
From: Marc Dietrich @ 2014-09-20 20:44 UTC (permalink / raw)
To: Wang Shilong; +Cc: Holger Hoffstätte, linux-btrfs
Hi,
Am Samstag 20 September 2014, 22:04:16 schrieb Wang Shilong:
> Hi,
>
> just my two cents here.^_^
>
> > Am Freitag, 19. September 2014, 13:51:22 schrieb Holger Hoffstätte:
> >> On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:
> >>> I have a particularly uncomplicated setup (a desktop PC with a hard
> >>> disk) and I'm seeing particularly slow performance from btrfs. A `git
> >>> status` in the linux source tree takes about 46 seconds after dropping
> >>> caches, whereas on other machines using ext4 this takes about 13s. My
> >>> mail client (evolution) also seems to perform particularly poorly on
> >>> this setup, and my hunch is that it's spending a lot of time waiting on
> >>> the filesystem.
> >>
> >> This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
> >> whatever you want to call it. git relies a lot on fast stat() calls,
> >> and those seem to be particularly slow with btrfs esp. on rotational
> >> media. I have the same problem with rsync on a freshly mounted volume;
> >> it gets fast (quite so!) after the first run.
> >
> > my favorite benchmark is "ls -l /usr/bin":
> >
> > ext4: 0.934s
> > btrfs: 21.814s
>
> I did a quick benchmark for this:
>
> Testing tool is something like follows, it create 50W files
> and 50w directories under a fresh mkfs filesystem, btrfs is just
> a little slower than ext4:
>
> For ext4:
> real 0m9.295s
> user 0m2.252s
> sys 0m7.010s
>
> For btrfs:
> real 0m10.207s
> user 0m1.347s
> sys 0m8.353s
>
> And test is done with a 20G vm disk(backend is hard disk) with
> latest kernel compiled under VM.
thanks for testing! However, I think a "double cached" VM disk may not be a
good test candidate.
> #!/bin/bash
>
> umount /dev/sdc
> #~/source/e2fsprogs/misc/mke2fs -F -O inline_data /dev/sdc >/dev/null
> mkfs.ext4 -F /dev/sdc >/dev/null
> mount /dev/sdc /mnt
> ./mdtest -d /mnt/ext4 -n 500000 -C >&/dev/null
> echo 3 > /proc/sys/vm/drop_caches
> time ls -l /mnt/ext4/\#test-dir.0/mdtest_tree.0 >& /dev/null
>
> umount /dev/sdc
> mkfs.btrfs -f /dev/sdc >/dev/null
> mount /dev/sdc /mnt
> ./mdtest -d /mnt/btrfs -n 500000 -C >/dev/null
> echo 3 > /proc/sys/vm/drop_caches
> time ls -l /mnt/btrfs/\#test-dir.0/mdtest_tree.0 >& /dev/null
ok, 500000 is much more than my 5000 files in /usr/bin, so ext4 needs a bit
more time. Also a fresh new btrfs may not reflect the same stage as an ageing
one. Unfortunately, I haven't found a method yet to find out the fragmentation
of a directory, so the question is why btrfs is that fast in your case ....
I did a small experiment:
mkdir /usr/bin2; cd /usr/bin2
for i in ../bin/*; do ln $i; done
echo 3 > /proc/sys/vm/drop_caches
time ls -l > /dev/null
real 0m5.935s
user 0m0.063s
sys 0m0.344s
better, so I think this is partly due to heavy fragmentation of the original
directory where even defrag does not help, but
btrfs fi defrag bin2
echo 3 > /proc/sys/vm/drop_caches
time ls -l > /dev/null
real 0m8.059s
user 0m0.080s
sys 0m0.381s
and
btrfs fi defrag -clzo bin2
echo 3 > /proc/sys/vm/drop_caches
time ls -l > /dev/null
real 0m12.524s
user 0m0.072s
sys 0m0.461s
times are +/- 1s in repeated tests.
so defragging seems to hurt in this case.
> So here i think Btrfs is not that you think much slower than Ext4 at least
> for ‘ls’ which means directory reading performances…
>
> Here i think you could do several ways to improve or avoid such things:
>
> 1. create a separate subvolume or separate partition for /usr and use
> noatime mount option if possible.(I remembered Marc MARLIEN gave some good
> example for this)
I have relatime, nodiratime and also compress=lzo.
> 2. running defrag command to reduce fragmentation.
I do this once per week on all directories via a cron job:
find / -xdev -type d -print -exec btrfs filesystem defragment -c '{}' \;
> Reasons for doing these are because that directory like /usr/bin is
> regularly accessed which will also trigger Btrfs widely COWed which may
> cause serious fragmentation and that may cause some bad performances..
and compression may also not benefit it.
> And another factor btrfs in default all files are mixed together in a a fs
> B-tree, which means that all read/write lock will walk through same tree
> which may cause some lock contention problem.
>
> So use a separate subvoulme tree could improve lock thing a bit for that
> IMO.
well, I have /, /var, and /usr on the same partition. So not so much
additional data (/home, /usr/src, /opt have their own partition).
> BTW, next time if someone reported some problems,it will be nice to
> give your detailed information for example kernel version, how many
> subvolumes/snapshots, btrfs file system configurations, usage(running btrfs
> file show,btrfs file df e.g.) these informations are useful for others to
> reproduce and analysis...
ok, for the sake of completness:
no subvolumes/snapshots (but merged two partitons),
nodiratime,relatime,compress=lzo,space_cache,autodefrag,
kernel 3.17rc5 (+btrfsprogs 3.17.x)
rotating media
# btrfs file show /
Label: 'root' uuid: 7e30aa9c-a7f0-456c-96c0-ee5c009bfe71
Total devices 2 FS bytes used 20.80GiB
devid 1 size 23.44GiB used 23.44GiB path /dev/sda6
devid 2 size 4.00GiB used 4.00GiB path /dev/sda10
# btrfs file df /
Data, single: total=25.40GiB, used=19.96GiB
System, single: total=32.00MiB, used=12.00KiB
Metadata, single: total=2.00GiB, used=857.67MiB
GlobalReserve, single: total=288.00MiB, used=0.00B
Regards,
Marc
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 12:18 Performance Issues Rob Spanton
` (3 preceding siblings ...)
2014-09-19 13:51 ` Holger Hoffstätte
@ 2014-09-19 15:05 ` Josef Bacik
2014-09-19 16:51 ` Rob Spanton
4 siblings, 1 reply; 29+ messages in thread
From: Josef Bacik @ 2014-09-19 15:05 UTC (permalink / raw)
To: rob, linux-btrfs
On 09/19/2014 08:18 AM, Rob Spanton wrote:
> Hi,
>
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s. My
> mail client (evolution) also seems to perform particularly poorly on
> this setup, and my hunch is that it's spending a lot of time waiting on
> the filesystem.
>
Weird, I get the exact opposite performance. Anyway it's probably
because of your file layouts, try defragging your git dir and see if
that helps. Thanks,
Josef
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance Issues
2014-09-19 15:05 ` Josef Bacik
@ 2014-09-19 16:51 ` Rob Spanton
2014-09-19 17:45 ` Josef Bacik
2014-09-20 5:58 ` Duncan
0 siblings, 2 replies; 29+ messages in thread
From: Rob Spanton @ 2014-09-19 16:51 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]
Hi,
Thanks for the response everyone.
I wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s. My
> mail client (evolution) also seems to perform particularly poorly on
> this setup, and my hunch is that it's spending a lot of time waiting on
> the filesystem.
The evolution problem has been improved: the sqlite db that it was using
had over 18000 fragments, so I got evolution to recreate that file with
nocow set. It now takes "only" 30s to load my mail rather than 80s,
which is better...
On Fri, 2014-09-19 at 11:05 -0400, Josef Bacik wrote:
> Weird, I get the exact opposite performance. Anyway it's probably
> because of your file layouts, try defragging your git dir and see if
> that helps. Thanks,
Defragging has improved matters a bit: it now takes 26s (was 46s) to run
git status. Still not amazing, but at the moment I have no evidence to
suggest that it's not something to do with the machine's hardware. If I
get time over the weekend I'll dig out an external hard disk and try a
couple of benchmarks with that.
For reference, these are the mount flags:
/dev/sda4 on / type btrfs (rw,noatime,space_cache)
/dev/sda4 on /home type btrfs (rw,noatime,space_cache)
Cheers,
Rob
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance Issues
2014-09-19 16:51 ` Rob Spanton
@ 2014-09-19 17:45 ` Josef Bacik
2014-10-30 14:23 ` Rob Spanton
2014-09-20 5:58 ` Duncan
1 sibling, 1 reply; 29+ messages in thread
From: Josef Bacik @ 2014-09-19 17:45 UTC (permalink / raw)
To: rob, linux-btrfs
On 09/19/2014 11:51 AM, Rob Spanton wrote:
> Hi,
>
> Thanks for the response everyone.
>
> I wrote:
>> I have a particularly uncomplicated setup (a desktop PC with a hard
>> disk) and I'm seeing particularly slow performance from btrfs. A `git
>> status` in the linux source tree takes about 46 seconds after dropping
>> caches, whereas on other machines using ext4 this takes about 13s. My
>> mail client (evolution) also seems to perform particularly poorly on
>> this setup, and my hunch is that it's spending a lot of time waiting on
>> the filesystem.
>
> The evolution problem has been improved: the sqlite db that it was using
> had over 18000 fragments, so I got evolution to recreate that file with
> nocow set. It now takes "only" 30s to load my mail rather than 80s,
> which is better...
>
> On Fri, 2014-09-19 at 11:05 -0400, Josef Bacik wrote:
>> Weird, I get the exact opposite performance. Anyway it's probably
>> because of your file layouts, try defragging your git dir and see if
>> that helps. Thanks,
>
> Defragging has improved matters a bit: it now takes 26s (was 46s) to run
> git status. Still not amazing, but at the moment I have no evidence to
> suggest that it's not something to do with the machine's hardware. If I
> get time over the weekend I'll dig out an external hard disk and try a
> couple of benchmarks with that.
>
> For reference, these are the mount flags:
> /dev/sda4 on / type btrfs (rw,noatime,space_cache)
> /dev/sda4 on /home type btrfs (rw,noatime,space_cache)
>
You have an awful lot of metadata, do you have a lot of snapshots? Also
I'd be interested in making sure most of this is just from shitty
metadata layout, could you make sure you have a recent version of
trace-cmd and then drop caches and do
trace-cmd record -e sched:sched_switch git status
and send me the trace.dat so I can see where all the time is spent? Thanks,
Josef
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 17:45 ` Josef Bacik
@ 2014-10-30 14:23 ` Rob Spanton
0 siblings, 0 replies; 29+ messages in thread
From: Rob Spanton @ 2014-10-30 14:23 UTC (permalink / raw)
To: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]
Hi Everyone,
I wrote:
> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs. A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s. My
> mail client (evolution) also seems to perform particularly poorly on
> this setup, and my hunch is that it's spending a lot of time waiting on
> the filesystem.
So I recently upgraded my desktop (now an i7-5820K on a Gigabyte
GA-X99-UD4 motherboard with 32GB of RAM), and moved the disk with this
problematic filesystem across to it. With this new setup, I still get
reasonably poor performance: the git status now takes ~26 seconds after
dropping caches. (Although note that this git repo has had been
repacked since I did the above benchmarks.)
I have also had the disk out on a USB-to-SATA adapter plugged into my
laptop, and seen similarly poor results.
So I've put the output of this command:
trace-cmd record -T -e sched:sched_switch -o /tmp/trace.dat git status
Here: http://robspanton.com/2014/10/trace.dat.xz
If anyone has any further ideas about how to remedy this situation,
please do let me know!
Cheers,
Rob
(Not subscribed to this list, so please CC me.)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance Issues
2014-09-19 16:51 ` Rob Spanton
2014-09-19 17:45 ` Josef Bacik
@ 2014-09-20 5:58 ` Duncan
1 sibling, 0 replies; 29+ messages in thread
From: Duncan @ 2014-09-20 5:58 UTC (permalink / raw)
To: linux-btrfs
Rob Spanton posted on Fri, 19 Sep 2014 17:51:09 +0100 as excerpted:
> The evolution problem has been improved: the sqlite db that it was using
> had over 18000 fragments, so I got evolution to recreate that file with
> nocow set. It now takes "only" 30s to load my mail rather than 80s,
> which is better...
>
> On Fri, 2014-09-19 at 11:05 -0400, Josef Bacik wrote:
>> Weird, I get the exact opposite performance. Anyway it's probably
>> because of your file layouts, try defragging your git dir and see if
>> that helps. Thanks,
>
> Defragging has improved matters a bit: it now takes 26s (was 46s) to run
> git status. Still not amazing, but at the moment I have no evidence to
> suggest that it's not something to do with the machine's hardware. If I
> get time over the weekend I'll dig out an external hard disk and try a
> couple of benchmarks with that.
[Replying via mail and list both, as requested.]
If you're snapshotting those nocow files, be aware (if you aren't
already) that nocow, snapshots and defrag (all on the same files) don't
work all that well together...
First let's deal with snapshots of nocow files.
What does a snapshot do? It locks in place the existing version of a
file, both logically, so you can get at that version of it via the
snapshot even after changes have been made, and physically, it locks
existing extents where they are. With normal cow files this is fine,
since any changes would cause the changed block to be written elsewhere,
freeing the now replaced block if there's nothing holding it in place. A
snapshot simply keeps a reference to the existing extent when the data is
cowed elsewhere instead of releasing it, so there's a way to get the old
version as referenced by that snapshot back too.
But nocow files are normally overwritten in place, that's what nocow
/is/. Obviously that conflicts with what a snapshot does, locking the
existing version in place.
What btrfs does, then, to handle that, is on the first write to a (4KB)
block in a (normally) nowcow file after a snapshot, a cow write is forced
on that block anyway. The file remains nocow, and additional writes to
the /same/ block continue to write to the same new location... until
another snapshot locks /that/ in place.
All fine if you're just doing occasional snapshots and/or if the nocow
file isn't being very actively rewritten after all; it's not that big a
deal in that case. *BUT*, if you're doing time-based snapshots say every
hour or so, and the file is actively being semi-randomly rewritten, the
constant snapshotting locking in place the current version, forcing many
of those writes to cow anyway, is going to end up fragmenting that file
nearly as fast as it would without the nocow. IOW, the nocow ends up
being nearly worthless on that file!
There is a (partial) workaround, however. You can use the fact that
snapshots stop at subvolume boundaries, putting the nocow files on their
own dedicated subvolume. You can then continue snapshotting the up-tree
subvolume as you were before and it'll stop at the dedicated subvolume,
so the nocow files on that subvolume don't get snapshotted and thus don't
get fragmented anyway.
Of course without that snapshotting you'll need to do conventional backup
on the files in that dedicated nocow subvolume.
Another alternative is to continue snapshotting the dedicated subvolume
and its nocow files, but at a lower frequency, perhaps every day or twice
a day instead of every hour, or maybe twice a week instead of daily, or
whatever. That will slow down but not eliminate the snapshot-triggered
fragmentation of the nocow files.
If you then combine that with scheduled (presumably cron job or systemd-
timer) defrag of that dedicated subvolume, perhaps weekly or monthly,
depending on how fast it still fragments, that can help keep performance
from dragging down too badly.
Of course you can use the scheduled defrag technique without the
dedicated subvolume and just up the frequency of the defrags instead of
decreasing the frequency of the snapshotting, too, if it works better for
you.
Meanwhile, how big are those files? If you're not dealing with any nocow-
candidate files approaching a gig or larger, you may find that the
autodefrag mount option helps. However, it works by queuing up a rewrite
of the entire file for a worker thread that comes along a bit later, and
if the file is too big and being written to too much, the changes to the
file can end up coming faster than the file can be rewritten. Obviously
that's not a good thing. Generally, for files under 100 MB autodefrag
works very well. For actively rewritten files over a GB, it doesn't work
well at all, and for files between 100 MB and 1 GB, it depends on the
speed of your hardware and how fast the rewrites are coming in.
Actually, most folks seem to be OK up to a quarter GiB or so, and most
folks have problems starting around 3/4 GiB or so. 256-768 MiB is the
YMMV zone.
Meanwhile, from what I've read sqlite apparently works best with under
half a gig of data to manage anyway, otherwise it's time to consider
scaling up to something like mysql/mariadb. So for most people, if all
they're dealing with is sqlite files, they're usually under half a gig in
size and the autodefrag mount option works at least reasonably well.
But I mentioned defrag as not working so well with snapshots too. The
problem there is somewhat different.
Before kernel 3.9 btrfs defrag wasn't snapshot aware -- it would defrag
just the current snapshot, leaving others in place. This of course
duplicated the data that defrag moved since the old locations couldn't be
freed as other snapshots were still referencing them, thus eating up
space rather faster than might have been expected.
With 3.9 defrag became snapshot aware, and would track and adjust all
reference to a block when defrag moved it. Unfortunately, that first
attempt had **HUGE** scaling issues -- defrags that should have taken
hours were taking days, even weeks, and multiple gigabytes of memory,
such that it was running into out-of-memory errors even on 16 and 32 GiB
RAM machines! (IIRC we had one report of it happening on a 64 gig
machine too!) Let alone the poor 32-bit folks! It turned out that
quotas and snapshots were the big culprits, and people with thousands of
snapshots (as can happen with snapper and the like if it's not set to
thin them out regularly) AND quotas enabled simply found defrag didn't
work at all for them.
So along about 3.12 (I'm not sure exactly), that first attempt at
snapshot-aware-defrag was disabled again, so people could at least /run/
defrag.
While they've rewritten various bits to scale MUCH better now, snapshot-
aware-defrag remains disabled for the time being.
Which means defrag is again only working on the current snapshot it is
pointed at, leaving other snapshots in place as they are. Which means if
you're snapshotting and defragging, and not deleting those snapshots
within a reasonable time, data usage is going to go up as defrag
duplicates the data it moves around, because it's only moving it around
for the current snapshot, the references other snapshots have to the
fragmented version remain in place, continuing to take up space until all
snapshots referencing the old blocks are deleted.
So if you're doing regular snapshots, try to keep them to a reasonably
limited time frame, with conventional backups if needed before that. If
you can keep snapshots to a month's time, great. But do try to keep it
to 60 or 90 days if possible. Beyond that, keep conventional backups if
you need to. And since btrfs is still under development and not fully
stable, such backups are strongly recommended anyway.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <CAEsGcVufqGYA3OMBUPnTBuXc0UxrrjJdFEr8kQXkLWbTcvd6Gw@mail.gmail.com>]
* Re: Performance issues
@ 2005-09-15 13:02 tmp123
0 siblings, 0 replies; 29+ messages in thread
From: tmp123 @ 2005-09-15 13:02 UTC (permalink / raw)
To: netfilter
> From what you explain i would guess for PMTU issues. Any
> chance that some other
> rule (in FORWARD chain) is blocking ICMP on this device?
>
> Regards
>
> Andreas
>
Hi Andreas,
Thanks for getting back to me. No, for testing purposes I
made sure that the NAT rule is the only rule in the entire
system, and the default policies are set to ACCEPT etc.
Regards,
Ferry van Aesch
^ permalink raw reply [flat|nested] 29+ messages in thread
* Performance issues
@ 2005-09-14 19:53 Ferry van Aesch
2005-09-15 12:43 ` TheGesus
2005-09-15 12:53 ` lst_hoe01
0 siblings, 2 replies; 29+ messages in thread
From: Ferry van Aesch @ 2005-09-14 19:53 UTC (permalink / raw)
To: netfilter
Hi,
Gents, I'm using 2.6.13-1 (same results with 2.4.27 though). I have a PIII 550Mhz with 4 3Com NICs:
Bus 0, device 12, function 0:
Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 120).
IRQ 5.
Master Capable. Latency=80. Min Gnt=10.Max Lat=10.
I/O at 0xe400 [0xe47f].
Non-prefetchable 32 bit memory at 0xfedffc00 [0xfedffc7f].
Bus 0, device 14, function 0:
Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (#2) (rev 120).
IRQ 10.
Master Capable. Latency=80. Min Gnt=10.Max Lat=10.
I/O at 0xf400 [0xf47f].
Non-prefetchable 32 bit memory at 0xfedff800 [0xfedff87f].
Bus 0, device 16, function 0:
Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev 0).
IRQ 9.
Master Capable. Latency=64. Min Gnt=3.Max Lat=8.
I/O at 0xe800 [0xe83f].
Bus 0, device 18, function 0:
Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (#2) (rev 0).
IRQ 11.
Master Capable. Latency=64. Min Gnt=3.Max Lat=8.
I/O at 0xe000 [0xe03f].
mii-diag output:
eth0:
mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x3000).
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0x3000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
End of basic transceiver information.
libmii.c:v2.11 2/28/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #24 transceiver registers:
3000 782d 0041 6800 05e1 41e1 0007 2801
0000 0000 0000 0000 0000 0000 0000 0000
0618 c011 0030 4001 40c8 a000 0000 0000
d300 0220 8084 9119 0065 1b69 7fff 0000.
Basic mode control register 0x3000: Auto-negotiation enabled.
Basic mode status register 0x782d ... 782d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:10:5a:--:--:--, model 0 rev. 0.
No specific information is known about this transceiver type.
I'm advertising 05e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 41e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Negotiation completed.
eth3:
mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x3100).
Basic mode control register 0x3100: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner is generating 10baseT link beat (no autonegotiation).
End of basic transceiver information.
libmii.c:v2.11 2/28/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #24 transceiver registers:
3100 786d 2000 5c01 01e1 0021 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0001 8060
8020 0c78 0000 3000 a3b9 0080 c305 001d.
Basic mode control register 0x3100: Auto-negotiation enabled.
Basic mode status register 0x786d ... 786d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 08:00:17:--:--:--, model 0 rev. 1.
Vendor/Part: National Semiconductor 83840A.
I'm advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 0021: 10baseT.
Negotiation did not complete.
Right now, I'm only using eth0 (the top one) and eth3 (the bottom one). Eth1 and eth2 have no cables plugged in.
eth0 has a PPPoE connection to an ISP (ADSL, 2mbit/128kbit, through a Netopia router in bridge mode).
On eth3 I have the rp-pppoe-server running, with a number of pppoe-sessions hanging off that. It's connected to a 10mbit hub (similar results with a 100mbit switch, 100baseTx-FD).
Now, the problem description is quite simple:
When I do a wget or ncftp or anything like that on the Linux machine, for instance I download a kernel from ftp.kernel.org, I get some 211KB/s. Nothing wrong with that for a 2mbit line.
When I do a big transfer over eth3 (so an ftp from the linux machine (server) to a windows machine (client) that is one of the pppoe-clients on eth3), I can easily saturate the 10mbit hub, and I get a good few megabit when using the switch. Again, nothing wrong with that.
Now for the problem. When I use one of those Windows clients to download something from the Internet (simple NAT rule in the nat table), I get a maximum of about 50KB/s. I can get it to go up to some 90KB/s when I play around with the TCP receive window size in the Windows registry, but a) that's still way too slow and b) I don't want to mess around with Windows registries.
When I force the transfers through a squid proxy on the Linux machine, I get 211KB/s again. Two seperate TCP streams in other words.
So, it seems that something is slowing things down a *lot* during the NAT step.
I've swapped out the hub for a 100mbit switch, to no avail. I've assigned an IP to eth3 and a windows machine (to get the pppoe-server out of the equation), but to no avail either. I do some HTB stuff on the pppoe-connections, but with those disabled (so the standard pfifo_fast re-instated), there's also zero in the difference.
It doesn't look like the CPU is going mad over it either, an uptime still shows 0.00 0.00 0.00, and the machine is very responsive, so I don't think that I'm draining the resources either (not that you'd expect that with only 2mbit...)
I've gone back to a 2.4 kernel, but the results are the same.
I'm a bit stumped really. I've set up numerous routers with 2.2 kernels (ipchains NAT though), with 3Com cards as well, and I've never had any performance issues, even with full 100mbit transfers through it.
The NAT rule is nothing spectacular either:
Chain POSTROUTING (policy ACCEPT 685 packets, 66775 bytes)
pkts bytes target prot opt in out source destination
240 17774 SNAT all -- * * 10.11.2.0/24 0.0.0.0/0 to:xx.xx.xx.xx
Does anyone know what could be going on here? I'd really appreciate some help: this machine is going to serve a rural broadband scheme here (wireless), so the 2mbit line is going to be something better, and there's going to be a good number of people tapping in to this. However, with a max throughput of 50KB/s, there's not much I can do.
If there's any other info that you might need, just ask!
Thanks in advance,
Ferry van Aesch
Ireland.
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: Performance issues
2005-09-14 19:53 Ferry van Aesch
@ 2005-09-15 12:43 ` TheGesus
2005-09-15 12:53 ` lst_hoe01
1 sibling, 0 replies; 29+ messages in thread
From: TheGesus @ 2005-09-15 12:43 UTC (permalink / raw)
To: netfilter
On 9/14/05, Ferry van Aesch <tmp123@bavirtual.org> wrote:
> Hi,
>
> Gents, I'm using 2.6.13-1 (same results with 2.4.27 though). I have a PIII 550Mhz with 4 3Com NICs:
> Bus 0, device 12, function 0:
> Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 120).
> IRQ 5.
> Master Capable. Latency=80. Min Gnt=10.Max Lat=10.
> I/O at 0xe400 [0xe47f].
> Non-prefetchable 32 bit memory at 0xfedffc00 [0xfedffc7f].
> Bus 0, device 14, function 0:
> Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (#2) (rev 120).
> IRQ 10.
> Master Capable. Latency=80. Min Gnt=10.Max Lat=10.
> I/O at 0xf400 [0xf47f].
> Non-prefetchable 32 bit memory at 0xfedff800 [0xfedff87f].
> Bus 0, device 16, function 0:
> Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev 0).
> IRQ 9.
> Master Capable. Latency=64. Min Gnt=3.Max Lat=8.
> I/O at 0xe800 [0xe83f].
> Bus 0, device 18, function 0:
> Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (#2) (rev 0).
> IRQ 11.
> Master Capable. Latency=64. Min Gnt=3.Max Lat=8.
> I/O at 0xe000 [0xe03f].
>
I see two 3c905Cs and two 3C905s. Two different chipsets. I don't
like that much, but it's a personal preference.
Regardless of your success in the past with 3com NICs, I would suggest
using something... ANYTHING... else. 3C90x's have been the bane of my
existence ever since they came out in the late 90s. If there is an S3
video chipset on that motherboard, it's a lost cause.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Performance issues
2005-09-14 19:53 Ferry van Aesch
2005-09-15 12:43 ` TheGesus
@ 2005-09-15 12:53 ` lst_hoe01
1 sibling, 0 replies; 29+ messages in thread
From: lst_hoe01 @ 2005-09-15 12:53 UTC (permalink / raw)
To: netfilter
Zitat von Ferry van Aesch <tmp123@bavirtual.org>:
> Hi,
[-- snip --]
>
> Right now, I'm only using eth0 (the top one) and eth3 (the bottom
> one). Eth1 and eth2 have no cables plugged in.
> eth0 has a PPPoE connection to an ISP (ADSL, 2mbit/128kbit, through a
> Netopia router in bridge mode).
> On eth3 I have the rp-pppoe-server running, with a number of
> pppoe-sessions hanging off that. It's connected to a 10mbit hub
> (similar results with a 100mbit switch, 100baseTx-FD).
>
> Now, the problem description is quite simple:
> When I do a wget or ncftp or anything like that on the Linux machine,
> for instance I download a kernel from ftp.kernel.org, I get some
> 211KB/s. Nothing wrong with that for a 2mbit line.
> When I do a big transfer over eth3 (so an ftp from the linux machine
> (server) to a windows machine (client) that is one of the
> pppoe-clients on eth3), I can easily saturate the 10mbit hub, and I
> get a good few megabit when using the switch. Again, nothing wrong
> with that.
>
> Now for the problem. When I use one of those Windows clients to
> download something from the Internet (simple NAT rule in the nat
> table), I get a maximum of about 50KB/s. I can get it to go up to
> some 90KB/s when I play around with the TCP receive window size in
> the Windows registry, but a) that's still way too slow and b) I don't
> want to mess around with Windows registries.
>
> When I force the transfers through a squid proxy on the Linux
> machine, I get 211KB/s again. Two seperate TCP streams in other words.
>
> So, it seems that something is slowing things down a *lot* during the
> NAT step.
>
> I've swapped out the hub for a 100mbit switch, to no avail. I've
> assigned an IP to eth3 and a windows machine (to get the pppoe-server
> out of the equation), but to no avail either. I do some HTB stuff on
> the pppoe-connections, but with those disabled (so the standard
> pfifo_fast re-instated), there's also zero in the difference.
>
> It doesn't look like the CPU is going mad over it either, an uptime
> still shows 0.00 0.00 0.00, and the machine is very responsive, so I
> don't think that I'm draining the resources either (not that you'd
> expect that with only 2mbit...)
>
> I've gone back to a 2.4 kernel, but the results are the same.
>
> I'm a bit stumped really. I've set up numerous routers with 2.2
> kernels (ipchains NAT though), with 3Com cards as well, and I've
> never had any performance issues, even with full 100mbit transfers
> through it.
>
> The NAT rule is nothing spectacular either:
> Chain POSTROUTING (policy ACCEPT 685 packets, 66775 bytes)
> pkts bytes target prot opt in out source
> destination
> 240 17774 SNAT all -- * * 10.11.2.0/24
> 0.0.0.0/0 to:xx.xx.xx.xx
From what you explain i would guess for PMTU issues. Any chance that
some other
rule (in FORWARD chain) is blocking ICMP on this device?
Regards
Andreas
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2014-10-30 14:23 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-19 12:18 Performance Issues Rob Spanton
2014-09-19 12:25 ` Swâmi Petaramesh
2014-09-19 12:58 ` Austin S Hemmelgarn
2014-09-19 12:49 ` Austin S Hemmelgarn
2014-09-19 12:59 ` Austin S Hemmelgarn
2014-09-19 13:34 ` Holger Hoffstätte
2014-09-22 11:59 ` David Sterba
2014-09-22 12:37 ` Holger Hoffstätte
2014-09-22 13:25 ` David Sterba
2014-09-19 13:51 ` Holger Hoffstätte
2014-09-19 14:53 ` Austin S Hemmelgarn
2014-09-19 16:23 ` Holger Hoffstätte
2014-09-19 17:51 ` Zach Brown
2014-09-20 8:23 ` Marc Dietrich
2014-09-20 13:41 ` Martin
2014-09-20 18:29 ` Chris Murphy
2014-09-20 14:04 ` Wang Shilong
2014-09-20 20:44 ` Marc Dietrich
2014-09-19 15:05 ` Josef Bacik
2014-09-19 16:51 ` Rob Spanton
2014-09-19 17:45 ` Josef Bacik
2014-10-30 14:23 ` Rob Spanton
2014-09-20 5:58 ` Duncan
[not found] <CAEsGcVufqGYA3OMBUPnTBuXc0UxrrjJdFEr8kQXkLWbTcvd6Gw@mail.gmail.com>
2012-10-06 16:49 ` performance issues corn chips
2012-10-06 16:50 ` Joao Eduardo Luis
-- strict thread matches above, loose matches on Subject: below --
2005-09-15 13:02 Performance issues tmp123
2005-09-14 19:53 Ferry van Aesch
2005-09-15 12:43 ` TheGesus
2005-09-15 12:53 ` lst_hoe01
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.