Messages in this thread | | | Date | Tue, 9 Nov 1999 16:35:28 -0700 | From | yodaiken@chelm ... | Subject | Re: PATCH 2.3.26: kmalloc GFP_ZEROt |
| |
On Wed, Nov 10, 1999 at 01:45:22AM +0100, Gerard Roudier wrote: > Indeed they may be used so, but it is the actual memory that will be > zeroed with the cache invalidating or snooping the accesses. May-be having > some pool of zeroed memory or zeroing some memory is useful for security > issue, but speaking of pooled or cached objects, we probably want to most > of the time reuse constructed instances that have been stated free and > only zero parts that need to be so. The bzero-mania does not look fine > programming to me.
Whenever we create a process, we are obligated to provide it with zeroed memory for security reasons. If we could optimize by eliminating all user processes, we would not need to bzero except for I/O blocks.
> PS: If we want to be able to write zero-filled blocks to a disk without > bzero overhead, for example, we can reserve a small amount of physical > pages filled with zeros at startup.
Allocate a disk block. Instantiate one inode in that block. Now write.
>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |