linux-kernel - Re: [PATCH] [2/2] Don't complain about disabled irqs when the system has paniced

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: <20080903102600.GP20055@kernel.dk>
Date:	Wed, 3 Sep 2008 12:26:01 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>, torvalds@...l.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [2/2] Don't complain about disabled irqs when the system has paniced

On Wed, Sep 03 2008, Nick Piggin wrote:
> > > For call_function_single, queueing could really help with high interrupt
> > > loads like the block completion migration that Jens has been looking at.
> >
> > But does it or not?
> 
> Well yes. It was basically impossible to implement without this IIRC,
> due to performance problems. And that code itself also showed some
> improvements in cases. I think it may need more tuning and testing.

The old code was useless for this, far too slow. With the new code I've
been able to demonstrate VERY good benefits from migrating interrupts,
both in synthetic cache locality benchmarks but also from something as
general as the compilebench test app (where reductions in system time
are as huge as 20-40%!). I hope to be able to share these results soon.
I have a rough profile from last week on XFS.

http://brick.kernel.dk/lock_rq0

vs

http://brick.kernel.dk/lock_rq1

rq0 is normal interrupt handling, rq1 is with rq_affinity set to 1 for
that block device queue. With that set, request completions are migrated
to the CPU that submitted them.

That is the whole reason why I got into generalizing the IPI function
call handling.

-- 
Jens Axboe

--
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/