RE: 2.5.59-mm2

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

> costly is a relative thing. a dozen cycles perhaps; do it once per
> 10 seconds and it's invisbile. I agree that if you want to do it thousands
> of times per second it might become a problem.But so far I don't see the
> real need for that.

Well, "complex" is a relative thing as well. At that time, we did not have a sophisticated algorithm to adjust the time period depending on the interrupt load. So today we may not see the difference. 

Anyway, I agree that complex things or policies should be moved to user mode as much as possible and the kernel should have the mechanism. And we'll take a look at your code. My point was that doing in user mode cannot justify wasting CPUs cycles for not good reasons.

Thanks,
Jun


> -----Original Message-----
> From: Arjan van de Ven [mailto:arjanv@redhat.com]
> Sent: Sunday, January 19, 2003 12:19 PM
> To: Nakajima, Jun
> Cc: arjanv@redhat.com; Andrew Morton; linux-mm@kvack.org; Kamble, Nitin A;
> Mallick, Asit K; Saxena, Sunil
> Subject: Re: 2.5.59-mm2
> 
> On Sun, Jan 19, 2003 at 11:45:35AM -0800, Nakajima, Jun wrote:
> > 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.
> 
> costly is a relative thing. a dozen cycles perhaps; do it once per
> 10 seconds and it's invisbile. I agree that if you want to do it thousands
> of times per second it might become a problem.But so far I don't see the
> real need for that.
> 
> > - 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.
> 
> if there's a bug there it needs fixing anyway; even inside the kernel
> you'll have a similar race I suspect
> 
> > 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,
> 
> there is rightfully a veto on such ABI and it's also not needed.
> /proc/interrupts is less than 4Kb normally; it'll be in cache so parsing
> it will be cheap. Sure the code I posted isn't optimal (far from it) but
> that can be optimized a lot.
> 
> 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/