linux-kernel - Re: [RFC PATCH] driver: loop: introduce synchronized read for loop driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <31091c95-1d0c-4e5a-a53b-929529bf0996@acm.org>
Date: Tue, 23 Sep 2025 09:30:00 -0700
From: Bart Van Assche <bvanassche@....org>
To: Zhaoyang Huang <huangzhaoyang@...il.com>,
 Christoph Hellwig <hch@...radead.org>
Cc: "zhaoyang.huang" <zhaoyang.huang@...soc.com>, Jens Axboe
 <axboe@...nel.dk>, Ming Lei <ming.lei@...hat.com>, linux-mm@...ck.org,
 linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
 steve.kang@...soc.com, Minchan Kim <minchan@...nel.org>
Subject: Re: [RFC PATCH] driver: loop: introduce synchronized read for loop
 driver

On 9/22/25 8:50 PM, Zhaoyang Huang wrote:
> 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.

More cgroups means more overhead from cgroup-internal tasks, e.g.
accumulating statistics. How about requesting to the Android core team
to review the approach of associating one cgroup with each PID? I'm 
wondering whether the approach of one cgroup per aggregate profile
(SCHED_SP_BACKGROUND, SCHED_SP_FOREGROUND, ...) would work.

Thanks,

Bart.