6 ms·

yes and pv processes are not scheduled on the same CPU core, so different L2 cache.

• daveguy 9y ago
  I wonder if `taskset -c1 yes | taskset -c1 pv > /dev/null` would significantly change the throughput.
  • joosters 9y ago
    $ yes |pv > /dev/null 46.6GiB 0:00:05 [9.33GiB/s] $ taskset 1 yes |taskset 1 pv > /dev/null 32.9GiB 0:00:05 [6.58GiB/s] $ taskset 1 yes |taskset 2 pv > /dev/null 45.7GiB 0:00:05 [9.13GiB/s] $ taskset 1 yes |taskset 4 pv > /dev/null 45.7GiB 0:00:05 [9.18GiB/s] Very rough numbers - the 9.13/9.33 difference flip-flopped when I ran the commands again. Binding both processes to the same core is definitely a performance hit though. There might be some gain through a shared cache, but it's lost more through lack of parallelism. I tried 2/4 as not sure how 'real' cores vs 'hyperthread' cores are numbered. These numbers are from a i7-7700k.
    • maxhou 9y ago
      How do you know that the dataset fits in L2 ? Assuming pv uses splice(), there is one only copy in the workload: copy_from_user() from fixed source buffer to some kernel allocated page, then those pages are spliced to /dev/null. If the pages are not "recycled" (through LRU scheme for allocation), the destination changes every time and the L2 cache is constantly trashed.
      • joosters 9y ago
        I only learned of pv from this article so I can't speak much about its buffering. I would guess that the kernel would try to re-use recent freed pages to minimise cache thrashing. But anyway, on the 'yes' side, the program isn't re-allocating its 8kb buffer after every write(), so there's a lot of data being re-read from the same memory location.