linux-kernel - Re: [Cluster-devel] dlm: Remove/bypass astd

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B7BF28E.5060405@redhat.com>
Date:	Wed, 17 Feb 2010 13:43:42 +0000
From:	Christine Caulfield <ccaulfie@...hat.com>
To:	Steven Whitehouse <swhiteho@...hat.com>
CC:	David Teigland <teigland@...hat.com>, cluster-devel@...hat.com,
	linux-kernel@...r.kernel.org
Subject: Re: [Cluster-devel] dlm: Remove/bypass astd

One of the reasons that ASTs are delivered in a separate thread was to 
allow ASTs do do other locking operations without causing a deadlock. 
eg. it would allow locks to be dropped or converted inside a blocking 
AST callback routine.

So maybe either the new code already allows for this or it's 
functionality that's not needed in the kernel. It should still be an 
option for userspace applications, but that's a different story 
altogether, of course

Chrissie

On 17/02/10 13:23, Steven Whitehouse wrote:
>
> While investigating Red Hat bug #537010 I started looking at the dlm's astd
> thread. The way in which the "cast" and "bast" requests are queued looked
> as if it might cause reordering since the "bast" requests are always
> delivered after any pending "cast" requests which is not always the
> correct ordering. This patch doesn't fix that bug, but it will prevent any
> races in that bit of code, and the performance benefits are also well
> worth having.
>
> I noticed that astd seems to be extraneous to requirements. The notifications
> to astd are already running in process context, so they could be delivered
> directly. That should improve smp performance since all the notifications
> would no longer be funneled through a single thread.
>
> Also, the only other function of astd seemed to be stopping the delivery
> of these notifications during recovery. Since, however, the notifications
> which are intercepted at recovery time are neither modified, nor filtered
> in any way, the only effect is to delay notifications for no obvious reason.
>
> I thought that probably removing the astd thread and delivering the "cast"
> and "bast" notifications directly would improve performance due to the
> elimination of a scheduling delay. I wrote a small test module which
> creates a dlm lock space, and does 100,000 NL ->  EX ->  NL lock conversions.
>
> Having run this test 10 times each on a 2.6.33-rc8 kernel and then the modified
> kernel including this patch, I got the following results:
>
> Original: Avg time 24.62 us per conversion (NL ->  EX ->  NL)
> Modified: Avg time 9.93 us per conversion
>
> Which is a fairly dramatic speed up. Please consider applying this patch.
> I've tested it in both clustered and single node GFS2 configurations. The test
> figures are from a single node configuration which was a deliberate choice
> in order to avoid any effects of network latency.
>
> Signed-off-by: Steven Whitehouse<swhiteho@...hat.com>
> ---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/