This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Wed, Feb 26, 2014 at 06:24:12PM +0100, OndÅej BÃlka wrote: > I did not said so, I said there could be minor regression and asked if > that is problem. Also there is problem of synchronization as independent > modifications would conflict and I want minimize these issue before they > happen Right, and I opined that it is a problem. There need to be more opinions on this so that a consensus can be achieved. > > You haven't understood why this is a bad idea. The pages will have > > been zeroed twice with your patch, once by mmap and again with memset. > > > I understood you perfecly and you are wrong here. Current implementation > also zeroes memory twice as this example demonstrates. Your point is > invalid here. Your example does not demonstrate that. Your example only demonstrates that the allocated memory is being touched, which is obvious since the metadata is written to the chunk. I am surprised that the kernel decided to page in the entire block for it though. If a chunk is mmapped, it is only memset if perturb_byte is set: /* Two optional cases in which clearing not necessary */ if (chunk_is_mmapped (p)) { if (__builtin_expect (perturb_byte, 0)) return memset (mem, 0, sz); return mem; } Siddhesh
Attachment:
pgpirAvegKbou.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |