Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1364515

Re: zram: per-cpu compression streams

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

Hello Minchan,

On (03/25/16 08:41), Minchan Kim wrote:
[..]
> >  Test #10 iozone -t 10 -R -r 80K -s 0M -I +Z
> >    Initial write        3213973.56      2731512.62      4416466.25*
> >          Rewrite        3066956.44*     2693819.50       332671.94
> >             Read        7769523.25*     2681473.75       462840.44
> >          Re-read        5244861.75      5473037.00*      382183.03
> >     Reverse Read        7479397.25*     4869597.75       374714.06
> >      Stride read        5403282.50*     5385083.75       382473.44
> >      Random read        5131997.25      5176799.75*      380593.56
> >   Mixed workload        3998043.25      4219049.00*     1645850.45
> >     Random write        3452832.88      3290861.69      3588531.75*
> >           Pwrite        3757435.81      2711756.47      4561807.88*
> >            Pread        2743595.25*     2635835.00       412947.98
> >           Fwrite       16076549.00     16741977.25*    14797209.38
> >            Fread       23581812.62*    21664184.25      5064296.97
> >  =          real         0m44.490s       0m44.444s       0m44.609s
> >  =          user          0m0.054s        0m0.049s        0m0.055s
> >  =           sys          0m0.037s        0m0.046s        0m0.148s
> >  
> >  
> >  so when the number of active tasks become larger than the number
> >  of online CPUS, iozone reports a bit hard to understand data. I
> >  can assume that since now we keep the preemption disabled longer
> >  in write path, a concurrent operation (READ or WRITE) cannot preempt
> >  current anymore... slightly suspicious.
> >  
> >  the other hard to understand thing is why do READ-only tests have
> >  such a huge jitter. READ-only tests don't depend on streams, they
> >  don't even use them, we supply compressed data directly to
> >  decompression api.
> >  
> >  may be better retire iozone and never use it again.
> >  
> >  
> >  "118 insertions(+), 238 deletions(-)" the patches remove a big
> >  pile of code.
> 
> First of all, I appreciate you very much!

thanks!

> At a glance, on write workload, huge win but worth to investigate
> how such fluctuation/regression happens on read-related test
> (read and mixed workload).

yes, was going to investigate in more details but got interrupted,
will return back to it today/tomorrow.

> Could you send your patchset? I will test it.

oh, sorry, sure! attached (because it's not a real patch submission
yet, but they look more or less ready I guess).

patches are against next-20160324.

	-ss

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: zram: per-cpu compression streams Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-23 09:20 +0100
  Re: zram: per-cpu compression streams Minchan Kim <minchan@kernel.org> - 2016-03-25 00:50 +0100
    Re: zram: per-cpu compression streams Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-25 02:50 +0100
      Re: zram: per-cpu compression streams Minchan Kim <minchan@kernel.org> - 2016-03-28 05:30 +0200
        Re: zram: per-cpu compression streams Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-30 10:40 +0200
          Re: zram: per-cpu compression streams Minchan Kim <minchan@kernel.org> - 2016-03-31 00:20 +0200
            Re: zram: per-cpu compression streams Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-31 03:30 +0200
              Re: zram: per-cpu compression streams Minchan Kim <minchan@kernel.org> - 2016-03-31 08:00 +0200
                Re: zram: per-cpu compression streams Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> - 2016-03-31 08:40 +0200
                Re: zram: per-cpu compression streams Sergey Senozhatsky <sergey.senozhatsky@gmail.com> - 2016-04-01 17:50 +0200

csiph-web