linux-kernel - Re: [PATCH] smp, ipi: Speed up IPI handling by invoking the callbacks in reverse order

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]

Date:	Thu, 5 Jun 2014 09:26:37 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
Cc:	akpm@...ux-foundation.org, fweisbec@...il.com, tglx@...utronix.de,
	hch@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] smp, ipi: Speed up IPI handling by invoking the
 callbacks in reverse order

On Thu, Jun 05, 2014 at 01:37:25AM +0530, Srivatsa S. Bhat wrote:
> On 06/05/2014 01:17 AM, Peter Zijlstra wrote:
> > On Thu, Jun 05, 2014 at 01:09:35AM +0530, Srivatsa S. Bhat wrote:
> >> The current implementation of lockless list (llist) has a drawback: if we
> >> want to traverse the list in FIFO order (oldest to newest), we need to
> >> reverse the list first (and this can be expensive if the list is large,
> >> since this is an O(n) operation).
> > 
> > Have you actually looked at the queue depth of this thing? Large queues
> > are a problem for interrupt latency.
> > 
> 
> Actually, I wrote this patch just by looking at the code and realizing
> that we don't need to reverse the list. In practice, I haven't actually
> seen any noticeable interrupt latencies or large queues so far. So I think
> this patch is just a very tiny optimization, that's all.

So conceptually it makes sense to service in FIFO because the first
entry is waiting longest, by servicing them in LIFO order you get far
more variance in latency.

And if the list is small, the cost isn't high.

Then again, we don't have any good numbers one way or the other.

Content of type "application/pgp-signature" skipped