linux-kernel - Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

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:	Mon, 6 Jun 2011 18:47:00 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	pageexec@...email.hu
Cc:	Andrew Lutomirski <luto@....edu>, x86@...nel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Jesper Juhl <jj@...osbits.net>,
	Borislav Petkov <bp@...en8.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Jan Beulich <JBeulich@...ell.com>,
	richard -rw- weinberger <richard.weinberger@...il.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Andi Kleen <andi@...stfloor.org>,
	Brian Gerst <brgerst@...il.com>,
	Louis Rilling <Louis.Rilling@...labs.com>,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH v5 8/9] x86-64: Emulate legacy vsyscalls

* pageexec@...email.hu <pageexec@...email.hu> wrote:

> On 6 Jun 2011 at 17:59, Ingo Molnar wrote:
> 
> > > > FYI, incredible amount of work has gone into making pagefaults as 
> > > > fast and scalable as possible.
> > > 
> > > i wasn't talking about scalability (it's irrelevant anyway here), 
> > > only speed. [...]
> > 
> > Which part of "fast and scalable" did you not understand?
> 
> uhm, not sure why you're so worked up here. is it because i said
> 'scalability' was completely irrelevant for the nx vsyscall page
> approach? elaborate!

Firstly, 'fast' is a necessary first step towards good scalability, 
secondly i was talking about *both* speed and scalability so your 
insistence to only discuss speed is banging on open doors ...

You are simply wrong about:

> > > sorry, but stating that the pf handler is a fast path doesn't 
> > > make it so ;).

and 5-6 mails down the line you are still unwilling to admit it. Why?

A fastpath is defined by optimization considerations applied to a 
codepath (the priority it gets compared to other codepaths), *not* by 
its absolute performance.

For example even though kmalloc() is about two orders of magnitude 
slower than the an unlikely() branch in the scheduler wakeup path, it 
is still kmalloc() that is the fastpath and the unlikely() branch in 
try_to_wake_up() is a slowpath.

You seem to be confused on several levels here.

Thanks,

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