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] |