On 06/08/2017 05:40 AM, Joonsoo Kim wrote: >>> >>> I don't understand why we trying to invent some hacky/complex schemes when we already have >>> a simple one - scaling shadow to 1/32. It's easy to implement and should be more performant comparing >>> to suggested schemes. >> >> >> If 32-bits work with the current approach, then I would also prefer to >> keep things simpler. >> FWIW clang supports settings shadow scale via a command line flag >> (-asan-mapping-scale). > > Hello, > > To confirm the final consensus, I did a quick comparison of scaling > approach and mine. Note that scaling approach can be co-exist with > mine. And, there is an assumption that we can disable quarantine and > other optional feature of KASAN. > > Scaling vs Mine > > Memory usage: 1/32 of total memory. vs can be far less than 1/32. > Slab object layout: should be changed. vs none. > Usability: hard. vs simple. (Updating compiler is not required) > Implementation complexity: simple. vs complex. > Porting to other ARCH: simple. vs hard (But, not mandatory) My main concern is a huge amount of complex and fragile code that comes with this patchset. Basically you are building a completely new algorithm on the fundamentals that were designed for the current algorithm. Hence you have to do these hacks with black shadow, tlb flushing, etc. Yes, it does consume less memory, but I'm not convinced that such aggressive memory saving are mandatory. I guess that for the most of the users (if not all) that currently unsatisfied with 1/8 shadow 1/32 will be good enough. FWIW I did run sanitized kernel (1/8 shadow) on the smart TVs with 1Gb of ram. > So, do both you disagree to merge my per-page shadow? If so, I will > not submit v2. Please let me know your decision. > Sorry, but it's a nack from me. > Thanks. > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
