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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1461570163-4083-1-git-send-email-dev@lynxeye.de>
Date:	Mon, 25 Apr 2016 09:42:43 +0200
From:	Lucas Stach <dev@...xeye.de>
To:	Dave Chinner <david@...morbit.com>
Cc:	xfs@....sgi.com, linux-kernel@...r.kernel.org
Subject: [PATCH] xfs: idle aild if the AIL is pushed up to the target LSN

The current logic only idles aild if the AIL is empty, rescheduling
the worker with a timeout of 50ms otherwise. If the target LSN isn't
moved forward, the worker will not make any progress as it only
pushes the AIL up to the target LSN, leading to the empty AIL
condition to only be met after the log worker pushed the complete
AIL. As the log worker runs on the scale of minutes, this leaves
aild in the "no progress, 50ms timeout" state for extended periods of
time, causing many unecessary wakeups.

Fix this by idling aild as soon as the AIL is pushed up to the target
LSN. All code paths that move the target LSN forward already ensure
that aild is woken up again when needed.

Signed-off-by: Lucas Stach <dev@...xeye.de>
---
I'm pretty sure that the above deduction is correct, but as this my
first real encounter with the XFS code base, someone with a bit more
knowledge than me should give this some thought.
---
 fs/xfs/xfs_trans_ail.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c
index d6c9c3e..7eca852 100644
--- a/fs/xfs/xfs_trans_ail.c
+++ b/fs/xfs/xfs_trans_ail.c
@@ -495,6 +495,7 @@ xfsaild(
 {
 	struct xfs_ail	*ailp = data;
 	long		tout = 0;	/* milliseconds */
+	struct xfs_log_item *lip;
 
 	current->flags |= PF_MEMALLOC;
 	set_freezable();
@@ -508,7 +509,8 @@ xfsaild(
 		spin_lock(&ailp->xa_lock);
 
 		/*
-		 * Idle if the AIL is empty and we are not racing with a target
+		 * Idle if the AIL is empty or pushed up to the requested
+		 * target LSN and we are not racing with a target
 		 * update. We check the AIL after we set the task to a sleep
 		 * state to guarantee that we either catch an xa_target update
 		 * or that a wake_up resets the state to TASK_RUNNING.
@@ -517,7 +519,8 @@ xfsaild(
 		 * The barrier matches the xa_target update in xfs_ail_push().
 		 */
 		smp_rmb();
-		if (!xfs_ail_min(ailp) &&
+		lip = xfs_ail_min(ailp);
+		if ((!lip || XFS_LSN_CMP(lip->li_lsn, ailp->xa_target) >= 0) &&
 		    ailp->xa_target == ailp->xa_target_prev) {
 			spin_unlock(&ailp->xa_lock);
 			freezable_schedule();
-- 
2.5.5

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ