linux-kernel - Re: [PATCH] create /proc/all-interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070730194206.GA17509@tsunami.ccur.com>
Date:	Mon, 30 Jul 2007 15:42:06 -0400
From:	Joe Korty <joe.korty@...r.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Sven-Thorsten Dietrich <sdietrich@...ell.com>,
	"H. Peter Anvin" <hpa@...or.com>, mingo@...e.hu,
	tglx@...utronix.de, linux-rt-users@...r.kernel.org,
	linux-kernel@...r.kernel.org, jason.baietto@...r.com
Subject: Re: [PATCH] create /proc/all-interrupts

On Mon, Jul 30, 2007 at 12:32:06PM -0700, Andrew Morton wrote:
> On Mon, 30 Jul 2007 10:33:17 -0700
> Sven-Thorsten Dietrich <sdietrich@...ell.com> wrote:
> > On Thu, 2007-07-26 at 11:56 -0700, H. Peter Anvin wrote: 
> > > Joe Korty wrote:
> > > > Create /proc/all-interrupts for some architectures.

> > 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.

Hi Andrew,
Thanks for the comments.  I'll, at least, make the changes you suggested.

(the /proc/interrupts version has the benefit of being smaller too).

Joe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/