|From:||"Larry H." <research-AT-subreption.com>|
|To:||Pekka Enberg <penberg-AT-cs.helsinki.fi>|
|Subject:||Re: [patch 0/5] Support for sanitization flag in low-level page allocator|
|Date:||Sat, 30 May 2009 14:33:11 -0700|
|Cc:||Rik van Riel <riel-AT-redhat.com>, Ingo Molnar <mingo-AT-elte.hu>, Alan Cox <alan-AT-lxorguk.ukuu.org.uk>, linux-kernel-AT-vger.kernel.org, Linus Torvalds <torvalds-AT-osdl.org>, linux-mm-AT-kvack.org, Ingo Molnar <mingo-AT-redhat.com>, pageexec-AT-freemail.hu, Linus Torvalds <torvalds-AT-linux-foundation.org>|
On 23:53 Sat 30 May , Pekka Enberg wrote: > Hi Rik, > > On Sat, May 30, 2009 at 11:39 PM, Rik van Riel <email@example.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/#kerne... 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, send a message with 'unsubscribe linux-mm' in the body to firstname.lastname@example.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"email@example.com"> firstname.lastname@example.org </a>
Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds