RE: 2.5.59-mm2

["Nakajima, Jun" <jun.nakajima@intel.com>]

We initially implemented it in user level, accessing /proc/interrupts. We have two issues/concerns at that point. And we saw better results with kernel mode.
- the data structures required, such as kstat, are already in the kernel and converting the text info from /proc/interrupts was costly in user mode.
- we suspect that frequent writes (asynchronous to interrupts) to /proc/irq/N/smp_affinity might expose a race condition in interrupt machinery. For example, we saw a hang caused by such a write.

So to implement it in user level efficiently, we need API that
- that provide binary data that can be easily processed by such a daemon,
- safer API to change routing. Or we need to take a closer look at /proc/irq/N/smp_affinity.

Thanks,
Jun


> -----Original Message-----
> From: Arjan van de Ven [mailto:arjanv@redhat.com]
> Sent: Saturday, January 18, 2003 12:13 PM
> To: Andrew Morton
> Cc: linux-mm@kvack.org; Kamble, Nitin A; Nakajima, Jun; Mallick, Asit K;
> Saxena, Sunil
> Subject: Re: 2.5.59-mm2
> 
> 
> > +kirq-up-fix.patch
> >
> >  Fix the kirq build for non-SMP
> 
> Hi,
> 
> Is there any reason to put this complexity in the kernel instead of
> doing it from a userspace daemon?
> 
> A userspace daemon can do higher level evaluations, read config files
> about the system (like numa configuration etc etc) and all 2.4/2.5
> kernels already have a userspace api for setting irq affinity..
> 
> an example of a simple version of such daemon is:
> http://people.redhat.com/arjanv/irqbalance/irqbalance-0.03.tar.gz
> 
> any chance of testing this in an intel lab?
> 
> Greetings,
>      Arjan van de Ven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/