LINUX.ORG.RU

DMA только на словах?

 ,


1

3

Почему копирование файлов загружает проц под завязку, оба ядра, в моем случае?

Я конечно гуглил на эту тему но не одного внятного ответа не нашел, правда были некоторы посты где говорили что под линуксом это так и есть, но без каких либо аргументов. Интересно я думал это проблема моего старого корыта, а нет, на 8ми поточном i7 оно тоже забирает все 13%.

Linux 3.16.0-48-generic #64~14.04.1-Ubuntu SMP Thu Aug 20 23:03:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

AMD Athlon(tm) II X2 265 Processor
DIMM DDR3 Synchronous 1333 MHz (0,8 ns)
970 Extreme4

Например 42Гб одним файлом из WDC WD5000AADS-0 на ST500LM012 HN-M5 (ФС ехт4)

 Model=ST500LM012 HN-M500MBB, FwRev=2AR10001, SerialNo=S2U3J9EC419059
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
 (maybe): CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-0,1,2,3,4,5,6,7

 Model=WDC WD5000AADS-00M2B0, FwRev=01.00A01, SerialNo=WD-WCAV5M828782
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
 BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=976773168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

[    1.685281] ata1: SATA max UDMA/133 abar m1024@0xfe40b000 port 0xfe40b100 irq 19
[    1.685283] ata2: SATA max UDMA/133 abar m1024@0xfe40b000 port 0xfe40b180 irq 19
[    1.685285] ata3: SATA max UDMA/133 abar m1024@0xfe40b000 port 0xfe40b200 irq 19
[    1.685287] ata4: SATA max UDMA/133 abar m1024@0xfe40b000 port 0xfe40b280 irq 19
[    1.685289] ata5: SATA max UDMA/133 abar m1024@0xfe40b000 port 0xfe40b300 irq 19
[    1.685290] ata6: SATA max UDMA/133 abar m1024@0xfe40b000 port 0xfe40b380 irq 19
[    2.179569] ata5.00: ATAPI: HL-DT-ST DVDRAM GH22NS50, TN02, max UDMA/100
[    2.183386] ata5.00: configured for UDMA/100
[    2.186138] ata2.00: ATA-8: WDC WD5000AADS-00M2B0, 01.00A01, max UDMA/133
[    2.186841] ata3.00: ATA-8: ST500LM012 HN-M500MBB, 2AR10001, max UDMA/100
[    2.187835] ata2.00: configured for UDMA/133
[    2.192544] ata1.00: ATA-8: KINGSTON SV300S37A60G, 505ABBF0, max UDMA/133
[    2.193183] ata3.00: configured for UDMA/100
[    2.202437] ata1.00: configured for UDMA/133
[ 9370.942786] ata5.00: configured for UDMA/100
[ 9370.958691] ata1.00: configured for UDMA/133
[ 9371.489050] ata3.00: configured for UDMA/100
[ 9380.104469] ata2.00: configured for UDMA/133
[13035.250645] ata5.00: configured for UDMA/100
[13035.266017] ata1.00: configured for UDMA/133
[13035.772476] ata3.00: configured for UDMA/100
[13044.504955] ata2.00: configured for UDMA/133

Ответ на: комментарий от anonymous

Не знаю, каждый раздел - все устройство... О каком выравнивании идет речь? Я об этом никогда не задумывался... Можно по подробнее?

DenisPA ★★ ()
Последнее исправление: DenisPA (всего исправлений: 1)

Ты бы почитал, что такое DMA, а также что такое файловая система.

Если кратко: копирование файла — это не просто тупое переписывание байтиков с одного места на жёстком диске на другое место.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от anonymous
sudo fdisk -l /dev/sdc
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000810bf

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048   976771071   488384512   83  Linux


sudo fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00012d66

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   976773119   488385536   83  Linux

DenisPA ★★ ()
Ответ на: комментарий от intelfx

Если кратко

Это не кратко, это никак.

Ты бы почитал, что такое DMA, а также что такое файловая система.

Намек непонятен, что же именно делает процессор что возникает заметная загрузка?

anonymous ()
Ответ на: комментарий от i-rinat

sudo perf top -a -d 1 -v
В приоритете copy_user_generic_string


mmap size 528384B
Looking at the vmlinux_path (6 entries long)
Using /proc/kcore for kernel object code
Using /proc/kallsyms for symbols
Failed to open /tmp/.gll7xnLp, continuing without symbols
Failed to open /tmp/perf-2271.map, continuing without symbols
Failed to open /tmp/perf-2405.map, continuing without symbols

PerfTop: 1580 irqs/sec kernel:49.1% exact: 0.0% [4000Hz cycles], (all, 2 CPUs)
-------------------------------------------------------------------------------

6.76% /lib/x86_64-linux-gnu/libc-2.19.so 0x8b83a
3.84% /proc/kcore 0x7fff8139599c
3.17% /lib/x86_64-linux-gnu/libc-2.19.so 0x870ca
2.38% /proc/kcore 0x7fff810f14b3
2.23% /proc/kcore 0x7fff81392d9a
2.08% /proc/kcore 0x7fff813921ad
1.84% /lib/x86_64-linux-gnu/libc-2.19.so 0x7fd98
1.59% /tmp/perf-vdso.so-l2EsRy 0xfcf
1.51% /lib/x86_64-linux-gnu/libc-2.19.so 0x8bcf3
1.46% /proc/kcore 0x7fff813955c7
1.43% /proc/kcore 0x7fff81391415
1.28% /proc/kcore 0x7fff810f09b5
1.08% /proc/kcore 0x7fff81394630
1.07% /proc/kcore 0x7fff8139377d
1.02% /lib/x86_64-linux-gnu/libc-2.19.so 0x6ef60
0.92% /proc/kcore 0x7fff81394ad0
0.76% /lib/x86_64-linux-gnu/libc-2.19.so 0x83271
0.74% /proc/kcore 0x7fff81396c70
0.72% /usr/lib/linux-lts-utopic-tools-3.16.0-48/perf 0x94c0c
0.68% /lib/x86_64-linux-gnu/libc-2.19.so 0x97fd0



http://pastebin.com/EyHdK5fU

DenisPA ★★ ()
Последнее исправление: DenisPA (всего исправлений: 2)
Ответ на: комментарий от intelfx

Так и запишем: линакс в 2015 году не умеет в DMA.

anonymous ()
Ответ на: комментарий от DenisPA

Всё вроде как норм, CPU тратится на копирование из ядра в пространство пользователя и обратно. Даже если нужно скопировать сплошной кусок с одного диска на другой, данные надо прочитать (DMA), потом скопировать из ядра в буфер пользователя, потом скопировать обратно в ядро и, наконец, записать на диск (DMA). Без DMA в операциях с диском ты упрёшься где-то в 33 МБ/c. Копирование в памяти — десятки ГБ/с, синхронное.

Какие скорости-то хоть?

i-rinat ★★★★★ ()

Посмотри биос -скорее всего включена совместимость с IDE ,включи наитивный режим ,иначе не включится планировщик очереди команд и dma 150 или 300 .

maximnik0 ★★ ()
Последнее исправление: maximnik0 (всего исправлений: 1)

Начиная с Linux 2.6.33 системный вызов sendfile позволяет копировать файл в файл. В таком случае данные не будут копироваться в юзерспейс и обратно, а пойдут по DMA. Обычный cp этого не делает

annulen ★★★★★ ()
Ответ на: комментарий от i-rinat

I don't plan to do that, since a few tests demonstrate no significant benefit.

Брешут'с

annulen ★★★★★ ()
Ответ на: комментарий от i-rinat

Я вот смотрел диспетчер задача под седьмым ведром там такие операции вообще не влияют на «картинку»... Както обидно получается...

Кстати вот сейчас смотрю htop и KDE System Monitor
у первого загрузка по двую ядрам 16%+16%, а у второго «пила» от 80 до 100%. Интересная разница, смотрю в /proc/stat кажется KDE прав. Тогда что показывает htop?

DenisPA ★★ ()
Ответ на: комментарий от i-rinat

few tests demonstrate

Ага, и без самих тестов и их результатов.

Держите говнокод для теста:

//c++ -std=c++1z -o sendfile sendfile.cc
#include<cassert>
#include<fcntl.h>
#include<sys/sendfile.h>
#include<sys/stat.h>

int main(int argc,char**argv){
  assert(argc==3);
  auto in=open(argv[1],O_RDONLY),
      out=creat(argv[2],S_IRUSR|S_IWUSR);

  struct stat stt;
  assert(in>=0 && out>=0 && !fstat(in,&stt) && S_ISREG(stt.st_mode));

  off_t off=0;
  while(1){
    auto res=sendfile(out,in,&off,0x7ffff000);
    assert(res>=0);
    if(!res)
      break;
    }
  }

anonymous ()

тьху блин! а я на планировщик вместе с 12309 грешил, а они оказывается такие ракалы

reprimand ★★★★★ ()
Ответ на: комментарий от DenisPA

Да неважно, команда «cp откуда куда» в консоли. Да?

anonymous ()

12309 закрыли же!

Теперь это не баг а фича!

anonymous ()
Ответ на: комментарий от DenisPA

Я не проверял, только убедился что работает.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.