Date:	Sat, 30 May 2009 14:33:11 -0700
From:	"Larry H." <research@...reption.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Rik van Riel <riel@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>,
	linux-mm@...ck.org, Ingo Molnar <mingo@...hat.com>,
	pageexec@...email.hu,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 0/5] Support for sanitization flag in low-level page
	allocator

On 23:53 Sat 30 May     , Pekka Enberg wrote:
> Hi Rik,
> 
> On Sat, May 30, 2009 at 11:39 PM, Rik van Riel <riel@...hat.com> wrote:
> >>> Have you benchmarked the addition of these changes? I would like to see
> >>> benchmarks done for these (crypto api included), since you are proposing
> >>> them.
> >>
> >> You have it the wrong way around. _You_ have the burden of proof here
> >> really, you are trying to get patches into the upstream kernel. I'm not
> >> obliged to do your homework for you. I might be wrong, and you can prove me
> >> wrong.
> >
> > Larry's patches do not do what you propose they
> > should do, so why would he have to benchmark your
> > idea?
> 
> It's pretty damn obvious that Larry's patches have a much bigger
> performance impact than using kzfree() for selected parts of the
> kernel. So yes, I do expect him to benchmark and demonstrate that
> kzfree() has _performance problems_ before we can look into merging
> his patches.

I was pointing out that the 'those test and jump/call branches have
performance hits' argument, while nonsensical, applies to kzfree and
with even more negative connotations (deeper call depth, more test
branches used in ksize and kfree, lack of pointer validation).

Also there's no kmem_cache_kzfree, either. There are some caches you
might want to look at.

Regarding the 'damn obvious much bigger performance impact': they have
none. You don't like it? Don't use the boot time option. And the next
version using a Kconfig option to disable it altogether is coming. Plus
I'll remove the sanitize_obj function altogether. Guess why I'm doing
that? Because there might be some benefit in trying to keep you happy
regarding that specific aspect of the patch.

Alan already pointed out this very clearly. Alan and I initially had
conflicting opinions about the first patches, we came to a point of
agreement. Rik also proposed changes, which I agreed upon and followed
up. They provided constructive critics and suggestions.

But you and the other cabal of vagueness have only sent mostly useless
comments, outright uncivil responses, obvious misdirection attempts,
unfounded critics, etc. I haven't seen more fallacies put together since
the last time I read an unreleased film script by Jerry Lewis.

If you think you have the power to decide when to cripple the kernel,
and what goes in or out by your own will, you missed the point about how
the Linux kernel became what it is today.

While we are at it, did any of you (Pekka, Ingo, Peter) bother reading
the very first paper I referenced in the very first patch?:

http://www.stanford.edu/~blp/papers/shredding.html/#kernel-appendix

Could you _please_ bother your highness with an earthly five minutes
read of that paper? If you don't have other magnificent obligations to
attend to. _Please_.

	Larry

PS: I'm still thanking myself for not implementing the kthread /
multiple page pool based approach. Lord, what could have happened if I
did.
> 
--
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/

Powered by blists - more mailing lists