Date: Thu, 7 Feb 2008 11:25:34 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: linux-kernel@vger.kernel.org, Alan.Brunelle@hp.com, arjan@linux.intel.com,
       dgc@sgi.com, npiggin@suse.de
Subject: Re: [PATCH 4/8] x86: add support for remotely triggering the block
	softirq
Message-ID: <20080207102534.GB16735@elte.hu>
References: <1202375945-29525-1-git-send-email-jens.axboe@oracle.com> <1202375945-29525-5-git-send-email-jens.axboe@oracle.com> <20080207100738.GB7716@elte.hu> <20080207101727.GE15220@kernel.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20080207101727.GE15220@kernel.dk>
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1113
Lines: 25


* Jens Axboe <jens.axboe@oracle.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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/