linux-kernel - Re: [RFC][PATCH] x86: Lazy disabling of 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]

Date:	Wed, 9 Oct 2013 20:36:27 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"H. Peter Anvin" <hpa@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Clark Williams <williams@...hat.com>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Kleen\, Andi" <andi.kleen@...el.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [RFC][PATCH] x86: Lazy disabling of interrupts

On Wed, 09 Oct 2013 15:25:23 -0700
Andi Kleen <andi@...stfloor.org> wrote:

> "H. Peter Anvin" <hpa@...ux.intel.com> writes:
> 
> >> Summary
> >> -------
> >> 
> >> Although the extreme case shows a nice improvement, I'm skeptical if it
> >> is worth doing for real world applications.
> >
> > You did the experiment, and credit to you for not going "I did the work,
> > now include it" but rather for publishing the results so we can learn
> > from them.
> >
> > It *does* make me wonder if we can leverage RTM for a significant subset
> > of these (as an interrupt will abort a transaction); that should be
> > substantially cheaper and less complex.
> 
> I miss the original context and can't find the original patchkit, but:

Yeah, for some reason, the original email didn't make it to LKML.

Dave,

I don't know why my email never reached LKML, was there something about
it that prevented it from going? The total character length was 46,972,
well below the 100,000 limit. Also the Cc list wasn't that big. Did my
ISP get flagged as a spam bot or something?

I can bounce it to you to see what was wrong with it.

-- Steve

> 
> - If the goal is to lower interrupt latency then RTM would still
> need to use a fallback, so the worst case would be the fallback, thus
> not be better.
> 
> - If the goal is to make CLI/STI faster:
> I'm not sure RTM is any faster than a PUSHF/CLI/POPF pair. It may
> well be slightly slower in fact (guessing here, haven't benchmarked)
> 
> - Also when you abort you would need to reexecute of course.
> 
> - My TSX patchkit actually elides CLI/STI inside transactions
> (no need to do them, as any interrupt would abort anyways)
> but the main motivation was to avoid extra aborts.
> 
> - That said, I think a software CLI/STI is somewhat useful for profiling,
> as it can allow to measure how long interrupts are delayed
> by CLI/STI.  I heard use cases of this, but I'm not 
> sure how common it really is
> 
> [I presume a slightly modified RT kernel could also give the same
> profiling results]
> 
> -Andi
> 

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