Re: [PATCH v6 09/13] zram: split zcomp into separate R/W streams

[Hillf Danton]

On Sat, 24 Oct 2026 18:14:00 +0800 Hillf Danton wrote:
>On Sat, 24 Oct 2026 14:48:32 +0900 Sergey Senozhatsky wrote:
>> On (26/10/23 19:40), Hillf Danton wrote:
>> [..]
>> > > writers vs readers 3 runs
>> > > 
>> > >     BASE+PE     IOPS 1,271k  avg 5.57us  sd 1,393us  p99.99 27.5us  max 1,581,800us
>> > >                 IOPS 1,461k  avg 3.43us  sd    78us  p99.99 23.9us  max   227,015us
>> > >                 IOPS 1,444k  avg 3.48us  sd   222us  p99.99 23.9us  max   592,628us
>> > >     PATCHED+PE  IOPS 1,457k  avg 3.32us  sd    18us  p99.99 27.5us  max     5,620us
>> > >                 IOPS 1,464k  avg 3.31us  sd    17us  p99.99 24.2us  max     5,621us
>> > >                 IOPS 1,475k  avg 3.29us  sd    16us  p99.99 26.5us  max     5,620us
>> 
>> BASE+PE looked noisy, so I sat down and tested properly (also tested
>> zstd and various compression levels).
> 
> Lets see the data from another pov (feel free to disagree) -- in the android
> phone/car cockpit environment, the render frequence is required above 60HZ,
> IOW a frame rendered within 16ms, so what share of the 16ms does the IOPS
> account for after this patchset, for example when an app in background is
> brought foreground?
>
I mean cpu cycles are burned to reclaim pages, given zram and swapout/in, OTOH
given whatever a GPU, slow or fast, if it would take more than 16ms to render
a frame, then there is no cure for the dilemma.