On Mon, Apr 11, 2022 at 3:53 PM Jan Kara <jack@xxxxxxx> wrote: > > On Tue 29-03-22 10:49:02, Amir Goldstein wrote: > > The ioctl can be used to request allocation of marks with large size > > and attach them to an object, even if another mark already exists for > > the group on the marked object. > > > > These large marks serve no function other than testing direct reclaim > > in the context of mark allocation. > > > > Setting the value to 0 restores normal mark allocation. > > > > FAN_MARK_REMOVE refers to the first mark of the group on an object, so > > the number of FAN_MARK_REMOVE calls need to match the number of large > > marks on the object in order to remove all marks from the object or use > > FAN_MARK_FLUSH to remove all marks of that object type. > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > I understand this is useful as a debugging patch but I'm not sure we want > this permanently in the kernel. I'm wondering if generally more useful > approach would not be to improve error injection for page allocations to > allow easier stressing of direct reclaim... I think you are probably right, but I had to stay within time budget to create a reproducer and it took me a lot of time even with this hack so I don't see myself investing more time on a reproducer with improved error injections. So for me, it is an adequate solution to carry this patch out-of-tree along with a matching out-of tree patch for LTP test: https://github.com/amir73il/ltp/commit/383db59959c44bb27dbec81e74d1d9caba45b0f2 For the community, we could rely on lockdep reports users now that we sorted out the lockdep annotations. BTW, before resorting to this ioctl I also started going down the path of running the test inside a restricted memcg, only to figure out that it is the inodes that need to be evicted not the marks and inodes are not accounted to memcg. I think there may have been some work in the direction of somehow accounting inode cache to memcg, but not sure where this stands. I am open for other suggestions. Thanks, Amir.
