linux-kernel - Re: [PATCH 4/8] x86: add support for remotely triggering the block softirq

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, 7 Feb 2008 11:25:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	linux-kernel@...r.kernel.org, Alan.Brunelle@...com,
	arjan@...ux.intel.com, dgc@....com, npiggin@...e.de
Subject: Re: [PATCH 4/8] x86: add support for remotely triggering the block
	softirq


* Jens Axboe <jens.axboe@...cle.com> wrote:

> > on the more conceptual level, shouldnt we just move to threads 
> > instead of softirqs? That way you can become affine to any CPU and 
> > can do cross-CPU wakeups anytime - which will be nice and fast via 
> > the smp_reschedule_interrupt() facility.
> 
> That would indeed be nicer and not require any arch changes. I was 
> afraid it would be more costly than massaging the softirqs a bit 
> though, perhaps that is unfounded.

pick up the threaded softirq patches from -rt, those move all softirqs 
processing into kernel threads. I'd suggest to extend those via 
wakeup-from-remote functionality - it fits the construct quite 
naturally. You should also be able to directly observe any performance 
impact of threaded softirq handlers. (and if you find any, let me know 
so that we can make it faster :-)

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