On Tue, 21 Jan 2003, Tim Riley wrote: > > > Peter Jay Salzman wrote: > > > you'd think by now i'd know stuff like this. i'm embarrased to have to > > ask this, but here it goes. > > Don't be -- memory management is complicated and gets more so > everytime they improve the hardware. As a result, the vocabulary > can get esoteric. > > > > > > > i'm reading the man page for electric fence, and i'm not fully > > understanding the sections on EF_ALIGNMENT and "WORD-ALIGNMENT AND > > OVERRUN DETECTION". i feel like i "almost" understand them. > > > > i think i understand the concept of memory page as being the minimum > > chunk of memory the kernel handles internally (8192 bytes minimum > > allocation of memory on x86) and alignment, but i guess i don't know > > what a word is. > > > > More specifically, a page is a chunk of memory that the operating system > (or hardware) copies to disk (swap space) when you run out of memory -- aka > "page fault." To optimize this process, memory is allocated by the page. > > > > > for example, the man page says that malloc() may be required to return > > word aligned memory pages, so in the diagram: > > > > This implies that malloc() may return more memory than you request. > It might be that malloc( 1 ) gets you an entire page -- 4 or 8 K. However, > subsequent malloc( 1 )s will just fill in the existing page. When it fills > up you > get a new page. > > The gcc complier knows about page alignments and will allocate > memory requested on the stack effeciently. So, whenever I need > string space, I'll do: "char buffer[ 1024 ];" because I believe that > "char buffer[ 1000 ];" gets me 1024 anyway.
a) malloc() affects heap memory, not stack memory. b) Don't forget that malloc() is a library call that uses data structures to keep track of allocated memory. Some implementations reserve some memory for allocated memory, while others simply take over freed memory and ignore allocated memory. An implementation that keeps track of allocated memory will allocate more than you ask for, and use teh extra for its own uses. My point is that your "optimization" is rather implementation-specific... it can backfire if the code is ported, yielding less efficient use of memory by requiring two pages instead of one. (If you don't mind some platform dependencies in your search for performance, this may be par for the course.) > > > > > 1 page allocated by malloc() > > x ------------ > > x+1 | | > > x+2 | 8192 | > > | bytes on | > > | x86 | > > | | > > ------------ > > > > i guess that places a restriction on what "x" is, but because i don't > > know what a word is, i don't know what that restriction is. > > > > what's a word? :) > > > > A word is the minimum amount of addressable memory. So, if you > declare "char c;" on the stack of a 386, even though you plan on storing > only 8 bits, more bits are available. To figure out the word size, take > the log based 2 of the constant UINT_MAX + 1 (in limits.h) -- probably > it's 32. Actually, the minimum amount of addressable memory is more commonly referred to as a byte. (Technically, the minimum amount of addressable memory _large enough to represent any printable character in the "C" locale_ is a byte... some architectures can address bits.) A word is the natural unit of data that can be moved from memory to a processor register. [1] Most modern processors have data paths composed of multiple bytes, and separate "enable" signals allow smaller units of data than a "word" to be read or written. This definition differs from the x86 version, which is fixed by convention at 16 bits to support upward software compatibility for certain compilers and assemblers. It may be inefficient to move a "word" around that is not stored beginning with the first addressable byte in the data bus. Part of the word has to be read in one bus operation, and the rest in a second bus operation. This is strongly discouraged on some architectures, to the point that they won't support such memory accesses directly, preferring instead to raise an exception (interrupt). Even if it is allowed, it represents a performance hit that can be avoided if data is laid out properly. > > > > > or does it mean that there's a restriction on *size* of the page and not > > the starting point? > > > > The page size is set by the hardware, and the Linux kernel manages paging > transparently. I'm surprised to hear about an application that is forcing > you > to make decisions about memory alignment. It isn't forcing the issue... simply providing it as an option to aid in identifying misaligned data accesses that could be a portability or performance problem. [1] http://WhatIs.techtarget.com/definition/0,,sid9_gci498438,00.html --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --------------------------------------------------------------------------- _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
