All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjanv@redhat.com>
To: "Nakajima, Jun" <jun.nakajima@intel.com>
Cc: arjanv@redhat.com, Andrew Morton <akpm@digeo.com>,
	linux-mm@kvack.org, "Kamble, Nitin A" <nitin.a.kamble@intel.com>,
	"Mallick, Asit K" <asit.k.mallick@intel.com>,
	"Saxena, Sunil" <sunil.saxena@intel.com>
Subject: Re: 2.5.59-mm2
Date: Sun, 19 Jan 2003 20:18:34 +0000	[thread overview]
Message-ID: <20030119201834.A3965@devserv.devel.redhat.com> (raw)
In-Reply-To: <3014AAAC8E0930438FD38EBF6DCEB5647D1492@fmsmsx407.fm.intel.com>; from jun.nakajima@intel.com on Sun, Jan 19, 2003 at 11:45:35AM -0800

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/

  reply	other threads:[~2003-01-19 20:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-19 19:45 2.5.59-mm2 Nakajima, Jun
2003-01-19 20:18 ` Arjan van de Ven [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-19 21:44 2.5.59-mm2 Nakajima, Jun
2003-01-19 22:05 ` 2.5.59-mm2 Andrew Morton
2003-01-18  8:20 2.5.59-mm2 Andrew Morton
2003-01-18  8:20 ` 2.5.59-mm2 Andrew Morton
2003-01-18 20:12 ` 2.5.59-mm2 Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030119201834.A3965@devserv.devel.redhat.com \
    --to=arjanv@redhat.com \
    --cc=akpm@digeo.com \
    --cc=asit.k.mallick@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=nitin.a.kamble@intel.com \
    --cc=sunil.saxena@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.