On Tue, Sep 23, 2025 at 2:09 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Mon, Sep 22, 2025 at 11:29:15AM +0800, zhaoyang.huang wrote: > > From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx> > > > > For now, my android system with per pid memcgv2 setup are suffering > > high block_rq_issue to block_rq_complete latency which is actually > > introduced by schedule latency of too many kworker threads. By further > > investigation, we found that the EAS scheduler which will pack small > > load tasks into one CPU core will make this scenario worse. This commit > > would like to introduce a way of synchronized read to be helpful on > > this scenario. The I2C of loop device's request reduced from 14ms to > > 2.1ms under fio test. > > So fix the scheduler, or create less helper threads, but this work > around really look like fixing the symptoms instead of even trying > to aim for the root cause. Yes, we have tried to solve this case from the above perspective. As to the scheduler, packing small tasks to one core(Big core in ARM) instead of spreading them is desired for power-saving reasons. To the number of kworker threads, it is upon current design which will create new work for each blkcg. According to ANDROID's current approach, each PID takes one cgroup and correspondingly a kworker thread which actually induces this scenario. >
