On Mon, 30 Jul 2007 10:33:17 -0700
Sven-Thorsten Dietrich <[email protected]> wrote:
> On Thu, 2007-07-26 at 11:56 -0700, H. Peter Anvin wrote:
> > Joe Korty wrote:
> > > Create /proc/all-interrupts for some architectures.
> > >
> > > Create a version of /proc/interrupts that displays _every_
> > > IRQ vector, not just those that someone thought might be
> > > interesting, and add an entry in the commentary column
> > > for those vectors which lacked such a comment.
> > >
> > > Rationale: /proc/interrupts is not truly useful unless it
> > > displays every IRQ vector, not just those somebody thought
> > > would be interesting. For example, since /proc/interrupts
> > > does not display the rescheduling interrupt, the occurance
> > > of rescheduling interrupt floods ends up affecting
> > > latencies, yet without an entry in /proc/interrupts, it
> > > is difficult to discern why latencies are being affected.
> > >
> > > Rather than modify /proc/interrupts, this patch creates
> > > a new version of /proc/interrupts, on the off-chance
> > > that adding new lines to /proc/interrupts, and appending
> > > new fields to the end of old lines, might break some
> > > longstanding script. However, these kinds of changes
> > > traditionally do not affect scripts, so it might be
> > > reasonable to fold /proc/all-interrupts back into
> > > /proc/interrupts.
> >
> > I think that would be the right thing to do. We have added things to
> > /proc/interrupts in the past.
> >
> Hi Andrew,
>
> Would it make sense to drop this patch into -mm for feedback?
>
It's a lot of code for something which might be useful to someone sometime.
It's a bit of a crappy changelog too. I'd at least like to see a list of
all the new fields.
It should be OK to add new lines to /proc/interrupts? That file varies a
lot between machines adn between architectures - as long as the new lines
have similar layout it is unlikely that anything will break.
+ atomic_inc(&__get_cpu_var(irq_thermal_counts));
The patch does atomic ops on cpu-local variables. This isn't needed, and
is expensive.
If the field is only ever modified from hard interrupt context then you can
make the field unsigned long and use plain old `foo++'.
If the field is modified from both hard-IRQ and from non-IRQ then use a
local_t and local_inc.
Or even, given that this is just a statistic and grrat precision is not
needed, use unsigned long and f++ even if that _is_ racy. Because the
consequences of a race will just be a single lost count, which we dont'
care about enough to add the additional overhead of an atomic op.
But I'm a bit dubious about the whole thing, really. As I said, it's a lot
of code. More justfication is needed for its addition, I'd suggest.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
